Payment identification code and payment system using the same

ABSTRACT

A payment method including determining whether a first routing identifier included in a payment instruction has routing information for a financial institution. The payment instruction also includes a payee-related identifier. If the first routing identifier is determined to include routing information for a financial institution, then a payment message is transmitted based on the first routing identifier, wherein the payment message includes the payee-related identifier. If the first routing identifier is determined to not include routing information for a financial institution, then (a) payee-related account identification information and a second routing identifier are retrieved based on the payee-related identifier, and (b) a payment message including the payee-related account identification information is transmitted to a payee-related destination, based on the second routing identifier. The payment message does not include at least one of the payee-related identifier and the first routing identifier.

This application claims the benefit of U.S. Provisional Application No.60/374,936, filed Apr. 23, 2002, the disclosure of which is herebyincorporated by reference in its entirety, as if fully set forth herein.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to systems and methods of makingelectronic payments. In particular, the present invention relates tosystems and methods for making payments to and from bankinginstitutions.

2. Description of the Related Art

With the emergence and adoption of the Internet and relatedtechnologies, businesses are moving toward electronic integration ofsupply and financial chains. Complete financial integration requires theability to issue information-rich, secure, private and guaranteed finalpayments.

Consumer-to-business e-payment has grown steadily over the past years,but business-to-business (B2B) e-payment growth has been much slower.Among the reasons for this lack of growth in B2B e-payments are the fearthat e-payments would lack remittance information and other vital data,and the reluctance to give out account numbers.

The current environment for payments involving businesses and banks isprimarily a paper one. The efficiency of paper processing has created aweak electronic bill payment infrastructure. Banks are at the center ofthe bill payment process. They hold customer accounts from whichpayments are authorized and are positioned to deliver the remittanceinformation to the biller. Banks are also positioned to deliver invoiceinformation to the biller's customers who are also the banks' customers.

In conventional non-electronic bill payment systems, where an ongoingrelationship exists, a party initiating payment (hereinafter “payor”)pays a debt to a biller by mailing a check in response to receipt of thebiller's invoice. The term “biller” is used to refer to the “payee” orentity to be paid. Attached to most biller's invoices is a paymentcoupon to be returned with the check. The coupon contains at least theconsumer-biller account number, as well as other information that willassist the biller, or the biller's bank, in properly crediting theconsumer (i.e., the party initiating payment) with payment.

The need to improve payment systems was recognized in the late 1960s.Special committees on paperless entries were formed and alternatives topaper checks were developed. From this early work, the first automatedclearing house (ACH) for the exchange of consumer-oriented paperlessentries was established. The early ACH associations worked with theirlocal Federal Reserve Bank to provide the facilities, equipment, andstaff to operate an automated clearing house. Ultimately this lead tothe development of the Electronic Payment Network (EPN), which is aprivate sector automated clearing house operator.

The ACH network is a low-cost electronic payment mechanism that can beused to pay both individual consumers and companies, regardless of size.In order to use the ACH network, bank routing information and payee(demand deposit account (DDA) identifier) account number must besupplied. This information must either be supplied by the initiator ofthe payment, or must be retained by the banking system of the payor.This presents a major problem that inhibits widespread use of the ACHnetwork because bank routing and account information of the payee israrely conveyed to payors for use in initiating payment instructions.

One type of system used in processing international and domesticpayments electronically is the Clearing House Interbank Payments System(CHIPS), which was established in 1970. CHIPS is the foremost means fortransferring U.S. dollars among world banks. In the CHIPS, a universalidentifier (UID) number is utilized that uniquely identifies individualcustomer accounts. The CHIPS UID number is a six-digit number that isused to identify named accounts at depository institutions on the CHIPS.

Another system used for processing electronic payment is the ElectronicPayment Network.

Because of the problems of security, authorization, authenticity, thefear that e-payments would lack remittance information and other vitaldata, and the reluctance of businesses to give out account numbers,there exists a need for a system and method that would enable theinitiation and receipt of electronic payments with full remittanceinformation that leverages the best features of existing electronicpayment systems, such as ACH EPN and CHIPS, as a backbone to the systemand method.

The need also exists for maintaining the confidentiality of accountinformation and provide ease of maintenance when an account holdertransfers from one depository institution to another.

Future enhancements to electronic bill payment will be integrated withexisting systems, including the present invention, to form a completesupply and financial chain integration, as depicted in FIG. 1.

As shown in FIG. 1, the iClearing & Settlement (iC&S) allows for modularimplementation wherein existing infastructures/processes, such as CHIPSand EPN, provide the basis for an electronic payment system. Envisionedis a new, future payment channel, XML of Rich Payment information thatallows the Buyer's Bank and the Seller's Bank to communicate directlywith the iC&S system for electronic payments. The Financial ServicesSolution provides adjudicated invoices to the Buyer's Bank and RichInformation (XML) to the Seller's Bank of buy and sell transactionsbetween a Buyer and Seller.

SUMMARY OF THE INVENTION

The present invention has been made to solve the above-explainedconventional problems, and it is an object of the invention to provide asecure electronic payment method.

It is another object of the invention to maintain the confidentiality ofaccount information. The objects of the invention are realized by amethod for effecting electronic payment between an originator's accountand a beneficiary's account, safeguarding banking and accountinformation, while utilizing existing payment systems, and to a systemthat operates in accordance with the method. The method comprisesgenerating a system routing number and a payment identification code(PIC) relating to the beneficiary's account information, distributing alist of payment identification codes to the existing payment system andfinancial institutions owning the account related to the paymentidentification codes on the list, and the originator receiving a systemrouting number and the beneficiary's PIC number. The method alsoincludes the originator communicating a payment instruction to afinancial institution of the originator, wherein the payment instructionincludes the system routing number beneficiary's payment identificationcode, the originator's financial institution receiving the paymentinstruction from the originator, wherein if the received PIC matches theoriginator's financial institution internal list of PICs, theoriginator's financial institution performs an “on us” transaction, andtransmitting a payment instruction to an existing payment system in acase where the received PIC does not match originator's financialinstitution internal list of PICs. The method further includes theexisting payment system validating the received PIC against a PICdatabase, wherein if the PIC is invalid, the payment instruction isreturned to the originator's financial institution, converting the PICand system routing number to a receiving payment instruction in a casewhere the PIC is a valid PIC, wherein the receiving payment instructionincludes the beneficiary's financial institution's routing number andthe beneficiary's account number. The existing payment system transmitsthe receiving payment instruction to a financial institution of thebeneficiary, the beneficiary's financial institution credits thebeneficiary's account if no problem exists, and otherwise returns areceiving payment instruction to the existing, payment system. Uponreceipt of the returned receiving payment instruction by the existingpayment system, the existing payment system translates the receivingpayment instruction into the payment instruction prior to transmittingthe payment instruction back to originator's financial institution,wherein the payment identification code is unique to each beneficiary'saccount.

According to another aspect of the present invention, a web-basedpayment method is provided for effecting electronic payment between anoriginator's account and a beneficiary's account utilizing existingpayment systems. The method includes generating a payment identificationcode and a system routing number uniquely identifying accountinformation of the beneficiary, distributing the payment identificationcode and the beneficiary's account information relating to the paymentidentification code to the existing payment systems, the beneficiarytransmitting the payment identification code to the originator, and inresponse to a payment order from the beneficiary, the originatortransmitting a payment instruction to the financial institution of theoriginator. The payment instruction includes the payment identificationcode of the beneficiary, and the amount to be paid. The method alsoincludes the originator's financial institution processing andtransmitting a payment instruction to an existing payment system toeffect an electronic funds transfer of funds, the existing paymentsystem converting a payment identification code included in a paymentinstruction to the beneficiary's account information and forwarding aconverted payment instruction to the beneficiary's financialinstitution, and the beneficiary's financial institution effecting anelectronic funds transfer on the basis of the converted paymentinstruction by crediting the beneficiary's account. According to oneembodiment of the invention the communications between the originator,the financial institution of the originator, the existing paymentsystem, the beneficiary's financial institution, and the beneficiary isaccomplished at least partly via the Internet, although in otherembodiments, at least some or all of the communication may take placevia any other suitable type of network of interest.

According to a further aspect of the present invention, a secureelectronic payment method between a consumer and a biller facilitatedthrough an existing payment system is provided. The method includesgenerating a payment identification code unique to a biller's accountinformation, distributing the payment identification code to the billerand the existing payment system, the biller communicating the paymentidentification code to the consumer, and the consumer electronicallytransmitting a payment instruction via the consumer's financialinstitution to the existing payment system. The payment instructionpreferably comprises information indicating at least source of theconsumer's account information, a payment amount, and the biller'spayment identification code. The method also includes the existingpayment system validating the payment identification code of the biller,and, upon validating the payment identification code of the biller, theexisting payment system converting the payment identification code ofthe biller included in the payment instruction into the biller's accountinformation which includes the routing number of the biller's financialinstitution. Further steps include transmitting the converted paymentinstruction to the biller's financial institution, applying a credit tothe biller's account in an amount corresponding to the payment amountincluded in the payment instruction, and applying a debit to theconsumer's account in an amount corresponding to the payment amountincluded in the payment instruction.

Further objects, features, and advantages of the present invention willbecome apparent from the following detailed description of the inventionwith reference to the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be more readily understood from a detaileddescription of the preferred embodiments taken in conjunction with thefollowing figures.

FIG. 1 is a block diagram of potential future integration of supply andfinancial chains;

FIG. 2 is a flowchart of the present invention integrated with the EPNsystem;

FIG. 3 is a flowchart of the present invention integrated with the CHIPSsystem;

FIG. 4 is a flowchart of the present invention integrated with analternate-CHIPS configuration;

FIG. 5 is an example of a cash management entry window;

FIG. 6 is an example of an entity-relationship diagram of the PICdatabase;

FIG. 7 is a functional process model depicting approach to definingbusiness requirements of the present invention;

FIGS. 8 and 9 are a flowchart of a create a bank profile;

FIG. 10 is a flowchart of a delete bank profile process;

FIG. 11 is a flowchart of a modify bank profile process;

FIG. 12 is a flowchart of a change route process;

FIG. 13 is a flowchart of a view PIC activity log process;

FIG. 14 is a flowchart of a view bank profile activity log process;

FIGS. 15A and 15B are a flowchart of a create user process;

FIGS. 16A and 16B are a flowchart of a delete user process;

FIGS. 17A and 17B are a flowchart of a modify user process;

FIG. 18 is a flowchart of a view user profile process;

FIG. 19 is a flowchart of a log on to the PIC system process;

FIG. 20 is a flowchart of a change password process;

FIG. 21 is a flowchart of a reset user process;

FIGS. 22A and 22B are a flowchart of a transfer PIC process;

FIG. 23 is a flowchart of a create PIC process;

FIGS. 24A and 24B are a flowchart of a close PIC process;

FIGS. 25A and 25B are a flowchart of a reactivate. PIC process;

FIG. 26 is a flowchart of a contest/release a PIC pending transferprocess;

FIGS. 27A and 27B are a flowchart of an approve a PIC activity process;

FIGS. 28A and 28B are a flowchart of a find a PIC process;

FIG. 29 is a flowchart of a flowchart of a view user profile activitylog process;

FIGS. 30A and 30B are a flowchart of a modify PIC process;

FIG. 31 is a flowchart of a perform trusted third party validationprocess;

FIG. 32 is a flowchart of a validate bank profile process;

FIGS. 33A and 3313 are a flowchart of an approve bank profilemodification process;

FIG. 34 is a block diagram of a PIC batch service.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The system using the payment identification code of the presentinvention will have the advantage of encouraging the use of electronicpayments between business buyers and sellers. To employ the concept,banks are issued a unique payment identifier code (PIC) number for eachbusiness customer demand deposit account (DDA). As part of the issuanceprocess, a trusted third party, such as a clearing house, for examplethe New York Clearing House, links sensitive information related to theseller and its individual DDA to the issued PIC number. Such a trustedthird party will set up a system (hereinafter “the system”) that will,among other things, maintain and distribute PIC numbers for all thatwish to use them. As a result, confidential account relationshipinformation is masked to outside parties. Individual sellers communicatetheir PIC numbers to buyers who are then capable of originating paymentsusing the PIC number. Upon receipt of a payment instruction containing avalid seller PIC number, a payment system, such as EPN or CHIPS, canthen access the PIC database to retrieve associated account informationrequired to execute the payment.

The use of the PIC number promises to deliver several benefits:

First, increased security. By safeguarding banking and accountinformation, corporations minimize the potential for fraudulent accountactivity. This benefit is very important for Internet-based transactionswhere counter-parties do not know each other. Also, it is envisionedthat the PIC number will be an integral component of theopen-standards-based payment channel of the future.

Second, portability. Preferably, individual PIC numbers will remain withbusiness customers regardless of changes in their banking relationshipsor account information such as address. As a result, corporations cancommunicate a single payment identification code to trading partners, acode that never changes.

Third, efficiency. Presently, 12 billion business-to-business checks arewritten each year. It is envisioned that the PIC number will be able tobe used by businesses that do not employ electronic payments as part oftheir financial operations. Reducing the number of paper-based paymentsincreases efficiency for all members of the financial chain.

Preferred embodiments of the system for implementing the presentinvention will now be discussed with reference to FIGS. 2 through 4.FIGS. 2 through 4, which are high-level block diagrams of the variousparties involved in the implementation and use of the preferredembodiments, show the PIC Process Definition and how the PIC conceptintegrates with the existing EPN and CHIPS payment systems. Hardwaresystems suitable for use by the various parties are well known in theart, and one of ordinary skill in the art is capable of implementingsuch systems as needed. In practice, it is expected that the system willutilize systems and communication infrastructure that are already inoperation. Also, the responsibilities of buyers, sellers and theirrespective financial institutions are outlined. While similar inconcept, many of the details associated with processing PIC paymentsvary between EPN-based and CHIPS-based transactions. It should be notedwhile the use of the PIC number will be explained with reference to theexisting EPN and CHIPS systems, this is for illustrative purposes onlyand the present invention is not limited to use with those systems.

FIG. 2 is a diagram illustrating the process utilizing the PIC of thepresent invention with the EPN system 2.3 As a pre-condition for theprocess steps described FIG. 2, a PIC number must be issued to the RDFI2.2 for the receiver's DDA. The RDFI 2.2 communicates a system routingnumber and PIC number to the receiver 2.1.

An originator 2.6 receives a system routing number and PIC number fromthe receiver 2.1. The originator 2.6 enters the system routing numberand the receiver's PIC number into the normal routing and account numberfields in either the cash management system supplied by the ODFI 2.5 orthrough its accounts payable system. An example of a cash managemententry interface is depicted in FIG. 5.

FIG. 5 shows a web-based cash manager system enabling the originator tomake a payment request. The cash management entry in FIG. 5 includes atleast the following fields vendor name (beneficiary/receiver) 5.1,vendor identification number 5.2, amount of payment 5.3, a paymentdescription 5.4, vendor bank identification 5.5, for which in thepresent embodiment the system routing number will be used, and a vendorbank account number 5.6 for which in the present invention the PICnumber will be used. Other fields can be added as necessary, dependingon each financial institution's requirements.

At step S1 of the flowchart in FIG. 2, the ODFI 2.5 receives a paymentrequest, identifies it as a system routing transaction by the routingnumber and checks the PIC number against an internal list of PIC numbersto determine if the receiver's 2.1 PIC number exists at the ODFI 2.5(i.e., to check if it is an “on-us” transaction). If the PIC numberindicates an on-us transaction, the ODFI 2.5 completes a book transferof funds, and the ODFI 2.5 debits the originator's account.

At step S2, if a PIC number match does not exist, the ODFI 2.5 sends thepayment instruction to the EPN system 2.3. At step S3, the EPN system2.3 validates the PIC number against the PIC database 2.4. If invalid,the payment instruction is returned to the ODFI 2.5 with an appropriateerror message. Once validated, the EPN system 2.3 replaces the systemrouting number and PIC number with the RDFI routing number and thereceiver's DDA number (not shown), and at step S4, payment informationis routed to the RDFI 2.2. At step S5, the RDFI 2.2 credits the receiverDDA.

At step S6, if there is a problem at the RDFI 2.2 receiving the payment,it is returned through the EPN system 2.3. The EPN system 2.3 recognizesreturns specific to the system and translates the DDA number back intothe system routing number and PIC number before returning the paymentinstruction to the ODFI 2.5.

At step S7, the RFDI 2.2 maintains PIC numbers related to their businesscustomer accounts through one of the system's service channels. At stepS8, the PIC database (not shown) on the EPN 2.3 is updated daily withchanges from the master PIC database 2.4. The master PIC database 2.4 isdescribed later.

FIG. 3 is a diagram illustrating the process utilizing the PIC of thepresent invention with the CHIPS system 3.4. As a pre-condition for theprocessing in FIG. 3, the system issues a PIC number for thebeneficiary's DDA to the beneficiary's bank 3.2. The beneficiary's bank3.2 communicates iC&S routing number and PIC number to the beneficiary3.1.

The originator 3.6 receives the system routing number and PIC numberfrom the beneficiary 3.1. The originator 3.6 enters the system routingnumber and the beneficiary's PIC number into the normal routing andaccount number fields in either the cash management system supplied byoriginator's bank 3.3 or the accounts payable system.

At step S10, the originator's bank 3.3 (also known as the CHIPS sendparticipant) receives a payment request and checks the PIC numberagainst internal list of PIC numbers to determine if the beneficiary'sPIC number is a business customer of the originator's bank 3.3.

At step S11, if a PIC number match does not exist, the originator's bank3.3 sends the payment instruction to CHIPS 3.4. At step S12, CHIPS 3.4validates the PIC number against the PIC database on CHIPS. If invalid,the payment is rejected and sent back to the originator's bank 3.3 withthe appropriate error message.

At step S13, once validated, CHIPS 3.4 replaces the system routingnumber and PIC number with the beneficiary bank's and (in this case) theCHIPS receive participant's routing number and the beneficiary's DDAnumber. At step S13, all payment information is routed to the CHIPSreceive participant (beneficiary bank) 3.2, and at step S14, thebeneficiary bank 3.2 credits the beneficiary's 3.1 DDA.

At step S13, the beneficiary bank 3.2 maintains PIC numbers related totheir customer accounts through one of the channels provided by thesystem (which is described later) and at step S16, the PIC database onCHIPS (not shown) is updated daily with changes from the master PICdatabase 3.5.

FIG. 4 is a diagram illustrating an alternative process utilizing thePIC of the present invention with the CHIPS 4.5 system (CHIPS withcorresponding bank). As a pre-condition for the process depicted in FIG.4, the system issues a PIC number to the beneficiary's bank 4.2 for thebeneficiary's 4.1 DDA. The beneficiary bank 4.2 communicates the systemrouting number and PIC number to receiver.

The originator 4.7 receives the system routing number and the PIC numberfrom the beneficiary 4.1. The originator 4.7 enters the system routingnumber and the beneficiary's PIC number into the normal routing andaccount number fields in either the cash management system supplied bythe originator's bank 4.3 or the accounts payable system.

At step S17, the originator's bank 4.3 and (in this case) the CHIPS sendparticipant receives the payment request and checks the PIC numberagainst an internal list of PIC numbers to determine if thebeneficiary's 4.1 PIC number is a business customer of the originator'sbank 4.3. At step S18, if a PIC number match does not exist, theoriginator's bank 4.3 sends the payment instruction to CHIPS 4.5.

At step S19, CHIPS 4.5 validates the PIC number against the PIC databaseon CHIPS. If invalid, the payment is rejected and sent back tooriginator's bank 4.3 with the appropriate error message. Oncevalidated, CHIPS 4.5 replaces the routing number and PIC number with theCHIPS receive participant's routing number and the beneficiary's 4.1 DDAnumber.

If the beneficiary's bank 4.2 is the CHIPS receive participant, thepayment is sent directly to the beneficiary bank 4.2 and the businesscustomer DDA is credited. In the illustrated case, the beneficiary'sbank 4.2 is not a CHIPS receive participant, so CHIPS 7.5 looks to thebeneficiary's 4.1 PIC for predetermined CHIPS receive participantrouting information.

At step S20, information on the entire CHIPS chain is included in thepayment instruction (beneficiary's bank 4.2 routing number andbeneficiary's 4.1 DDA number, name, address, etc.) and routed to theCHIPS receive participant 4.4. At step S21, the CHIPS receiveparticipant 4.4 receives the payment and forwards it to thebeneficiary's bank 4.2, and at step S22, the beneficiary's bank 4.2credits the beneficiary's 4.1 DDA.

At step S23, the beneficiary bank 4.2 maintains PIC numbers related totheir customer accounts through one of the channels provided by thesystem, and at step S24, the PIC database on CHIPS (not shown) isupdated daily with changes from the master PIC database 4.6.

To use the PIC enhancement of the present invention, participant banksmust fulfill certain requirements. These requirements include:

Connectivity. Initially, banks must either have an operationalconnection to SWIFTNet or ConnectDirect.

SWIFTNet is S.W.I.F.T's™ advanced IP-based messaging solution. SWIFTNetallows a financial institution to do business in an environment thatcombines the security of a private network and the guarantees of atrusted third party with the flexibility of Internet technologies.

ConnectDirect is a peer-to-peer file-based integration software forhigh-volume, assured file transfers. ConnectDirect automates the secure,reliable transfer of large volumes of data within and betweenenterprises. ConnectDirect is available only for those banks that arecurrently set up for file transfer. These connections are necessary toprovide a secure channel for enrollment and maintenance of PIC numbers.

ACH System Enhancement (Minor). Because the PIC number hides receivingbank information, originating banks do not know when they areoriginating “on us” transactions. Banks wishing to filter out “on us”PIC transactions may want to make modifications to their ACH originationmethods/systems. However, modifications are not required.

Resource Commitment. Banks must have the resources to supply anenrollment file extract, test the PIC system, and train their staff toservice PICs.

Other System Requirements. Programming changes may be required on thesending and the receiving sides of a transaction. However, the requiredchanges would be minor. For example, a sending bank may want to changethe cash management field labeled “account number” to “PIC number.” Or,the receiving bank may want to “track” all transactions involving thesystem.

For those banks that choose to pilot the PIC service, there are severaladditional requirements. These requirements include:

Fees. If a pilot bank cannot immediately identify and divert “on us” PICtransactions, the trusted third party can issue a credit for theestimated amount of “on-us” charges incurred during pilot activities.

Customer Identification. The pilot bank would preferably be required toidentify specific business customers whom they intend to partner withduring the PIC pilot for EPN. The criteria for pilot customers (buyersand sellers) include EPN/CHIPS registration. Both the buyer and sellerare required to be EPN registered bank customers. This requirementprevents the situation where a buyer sends a PIC-based transaction totheir bank who, in turn, send it to the Federal Reserve who will likelynot be able to process the transaction during the pilot phase.

The PIC database is housed in a relational database application. FIG. 6depicts an example of a structure of the PIC database. As isappreciated, there are countless configurations for a relationaldatabase depicting a PIC database. FIG. 6 only illustrates one suchpossible configuration, and in no way should be construed as limitingthe application of the inventive systems and methods to thatconfiguration. FIG. 6 shows a PIC database with 16 tables. Table 1 is asummary of the PIC database and describes each of the tables representedin FIG. 6. FIG. 6 and Table 1 are illustrative only of a PIC database.

TABLE 1 Database Summary Target DBMS: Microsoft SQL Server Number oftables:  16 Number of views:  0 Number of columns: 165 Number ofIndexes:  4 Number of foreign keys:  20 last map date: 1/2/1970 Extendedattributes: Filegroup F1 Filegroup F2 Fllegroup PRIMARY Tables ColumnsIndexes Foreign Keys Notes PICSTATUS 2 0 0 PICS 1 0 0 PICACTIVITY 41 2 7PICACTION 2 0 0 PICACCOUNTSTATUS 2 0 0 PIC 31 1 3 SYSTEMPARA 2 0 0SOURCE 2 0 0 BANKSTATUS 2 0 0 BANKROUTING 2 0 1 BANKPROFILE 29 0 3BANKACTIVITY 41 1 6 BANKACTION 2 0 0 ACTIVITYSTATUS 2 0 0 ACTIVITYDISP 20 0 ACCOUNTSTATUS 2 0 0 ACCOUNT STATUS Owner: dbo Target DB name: icnsNumber of columns: 2 Number of Indexes: 0 Number of foreign keys: 0Codes: 0 Type: 0 Extended Attributes: OnFileGroup PRIMARY Clustered PKYes Columns Data Type Allow NULLS Value/Range STATUSID tinyint Notallowed DESCRIPTION varchar(30) Not allowed Foreign keys Child ParentFK_BANKACTIVITY-ACCOUNT STATUS_EPN BANKACTIVITY.EPNFLAG STATUSIDFK_BANKACTIVITY-ACCOUNT STATUS_CHIPS BANKACTIVITY.CHIPSFLAG STATUSIDFK_BANKACTIVITY-ACCOUNT STATUS_EPN BANKACTIVITY.EPNFLAG STATUSIDFK_BANKACTIVITY-ACCOUNT STATUS_CHIPS BANKACTIVITY.CHIPSFLAG STATUSIDFK_BANKACTIVITY-ACCOUNT STATUS_EPN BANKACTIVITY.EPNFLAG STATUSID Columndetails 1. STATUSID Physical data type: tinyint Allow NULLs: Not allowed2. DESCRIPTION Physical data type: varchar(30) Allow NULLs: Not allowedACTIVITYDISP Owner: dbo Target DB name: icns Number of columns: 2 Numberof Indexes: 0 Number of foreign keys: 0 Codes: 0 Type: 0 ExtendedAttributes: OnFileGroup PRIMARY Clustered PK Yes Columns Data Type AllowNULLS Value/Range STATUSID tinyint Not allowed DESCRIPTION varchar(30)Not allowed Foreign keys Child Parent FK_BANKACTIVITY-ACCOUNT STATUS_EPNBANKACTIVITY.EPNFLAG STATUSID FK_BANKACTIVITY-ACCOUNT STATUS_CHIPSBANKACTIVITY.CHIPSFLAG STATUSID FK_BANKACTIVITY-ACCOUNT STATUS_EPNBANKACTIVITY.EPNFLAG STATUSID FK_BANKACTIVITY-ACCOUNT STATUS_CHIPSBANKACTIVITY.CHIPSFLAG STATUSID FK_BANKACTIVITY-ACCOUNT STATUS_EPNBANKACTIVITY.EPNFLAG STATUSID Column details 1. STATUSID Physical datatype: tinyint Allow NULLs: Not allowed 2. DESCRIPTION Physical datatype: varchar(30) Allow NULLs: Not allowed ACTIVITYSTATUS Owner: dboTarget DB name: icns Number of columns: 2 Number of Indexes: 0 Number offoreign keys: 0 Codes: 0 Type: 0 Extended Attributes: OnFileGroupPRIMARY Clustered PK Yes Columns Data Type Allow NULLS Value/RangeSTATUSID tinyint Not allowed DESCRIPTION varchar(30) Not allowed Foreignkeys Child Parent FK_BANKACTIVITY_ACTIVITYSTATUSBANKACTIVITY.ACTIVITYSTATUS STATUSID FK_BANKACTIVITY-ACTIVITY STATUSUPOCACTIVITY.CHIPSFLAG STATUSID Column details 1. STATUSID Physical datatype: tinyint Allow NULLs: Not allowed 2. DESCRIPTION Physical datatype: varchar(30) Allow NULLs: Not allowed BANKACTION Owner: dbo TargetDB name: icns Number of columns: 2 Number of Indexes: 0 Number offoreign keys: 0 Codes: 0 Type: 0 Extended Attributes: OnFileGroupPRIMARY Clustered PK Yes Columns Data Type Allow NULLS Value/RangeACTIONID tinyint Not allowed DESCRIPTION varchar(30) Not allowed Foreignkeys Child Parent FK_BANKACTIVITY_BANKACTIVITY_BANKACTIONBANKACTIVITY.ACTIONS ACTIONID Column details 1. ACTIONID Physical datatype: tinyint Allow NULLs: Not allowed 2. DESCRIPTION Physical datatype: varchar(30) Allow NULLs: Not allowed BANKACTIVITY Owner: dboTarget DB name: icns Number of columns: 41 Number of Indexes:  1 Numberof foreign keys:  6 Codes:  3 Type: Table User defined types: Name DataType BANKRTN N-Signed Integer CHIPSABA N-Signed Integer BANKRTN N-SignedInteger Clustered PK Yes Columns Data Type Allow NULLS Value/RangeACTIVITYID Int Identity Not allowed ACTIVITYDISP (FK) tinyint Notallowed APPLDATE datetime Allowed ACTIVITYSTATUS (FK) tinyint Notallowed CREATEDATE datetime Not allowed CREATEUSER varchar(40) Notallowed CREATESOURCE (FK) tinyint Not allowed APPRDATE datetime AllowedAPPRUSER varchar(40) Allowed CANCELDATE datetime Allowed CANCELUSERvarchar(40) Allowed ACTIONS (FK) tinyint Not allowed EFFDATE datetimeNot allowed BANKRTN (I1) BANKRTN Not allowed BANKNAME varchar(96) Notallowed EPNFLAG (FK) tinyint Not allowed CHIPSFALG (FK) tinyint Notallowed CHIPSABA CHIPSABA Allowed CHIPSLNKRTN BANKRTN Allowed CHIPSDDAvarchar(34) Allowed CHIPSDEPTH tinyint Allowed BANKTYPE varchar(3) NotAllowed ADD1 varchar(64) Allowed ADD2 varchar(64) Allowed ADD3varchar(64) Allowed ADD4 varchar(50) Allowed CITY varchar(32) AllowedSTATE varchar(32) Allowed ZIP varchar(11) Allowed COUNTRY char(3) NotAllowed PHONE Phone Allowed FAX Phone Allowed EMAIL email AllowedBACKPHONE Phone Allowed BACKFAX Phone Allowed BACKEMAIL email AllowedWPAYNA1 varchar(35) Allowed WPAYNA2 varchar(35) Allowed WPAYNA3varchar(35) Allowed WPAYNA4 varchar(35) Allowed COMMENTS varchar(80)Allowed Indexes Columns Sort Order IX_BANKACTIVITY_BANKRTN (I1) BANKRTNAscending Foreign keys Child Parent FK_BANKACTIVITY_ACCOUNTSTATUS_EPNEPNFLAG ACCOUNTSTATUS.STATUSID FK_BANKACTIVITY_ACCOUNTSTATUS_CHIPSCHIPSFLAG ACCOUNTSTATUS.STATUSID FK_BANKACTIVITY_ACTIVITYDISPACTIVITYDISP ACTIVITYDISP.DISPID FK_BANKACTIVITY_ACTIVITYSTATUSACTIVITYSTATUS ACTIVITYSTATUS.STATUSID FK_BANKACTIVITY_BANKACTIONACTIONS BANKACTION.ACTIONID FK_BANKACTIVITY_SOURCE CREATESOURCESOURCE.SOURCEID Column details Columns Data Type Allow NULLSValue/Range 1. ACTIVITYID Physical data type: int identity Allow NULLs:Not allowed 2. ACTIVITYDISP (FK) Physical data type: tinyint AllowNULLs: Not allowed 3. APPLDATE Physical data type: datetime Allow NULLs:Not allowed 4. ACTIVITYSTATUS (FK) Physical data type: datetime AllowNULLs: Not allowed 5. CREATEDATE Physical data type: datetime AllowNULLs: Not allowed 6. CREATEUSER Physical data type: varchar(40) AllowNULLs: Not allowed 7. CREATESOURCE (FK) Physical data type: tinyintAllow NULLs: Not allowed 8. APPRDATE Physical data type: datetime AllowNULLs: Not allowed 9. APPRUSER Physical data type: datetime Allow NULLs:Allowed 10 CANCELDATE Physical data type: datetime Allow NULLs: Allowed11 CANCELUSER Physical data type: varchar(40) Allow NULLs: Allowed 12ACTIONS (FK) Physical data type: tinyint Allow NULLs: Not Allowed 13.EFFDATE Physical data type: datetime Allow NULLs: Not allowed Defaultvalue: getdate( ) + 1 14. BANKRTN (I1) Physical data type: BANKRTN AllowNULLs: Not allowed 15. BANKNAME Physical data type: varchar(96) AllowNULLs: Not allowed 16. EPNFLAG (FK) Physical data type: tinyint AllowNULLs: Not allowed 17. CHIPSFLAG (FK) Physical data type: tinyint AllowNULLs: Not allowed 18. CHIPSABA Physical data type: CHIPSABA AllowNULLs: Allowed 19. CHIPSLINKRTN Physical data type: BANKRTN Allow NULLs:Allowed 20. CHIPSDDA Physical data type: varchar(34) Allow NULLs:Allowed 21. CHIPSDEPTH Physical data type: tinyint Allow NULLs: Allowed22. BANKTYPE Physical data type: varchar(3) Allow NULLs: Allowed 23.ADD1 Physical data type: varchar(64) Allow NULLs: Not Allowed 24. ADD2Physical data type: varchar(64) Allow NULLs: Allowed 25. ADD3 Physicaldata type: varchar(64) Allow NULLs: Allowed 26. ADD4 Physical data type:varchar(50) Allow NULLs: Allowed 27. CITY Physical data type:varchar(32) Allow NULLs: Allowed 28. STATE Physical data type:varchar(32) Allow NULLs: Allowed 29. ZIP Physical data type: varchar(11)Allow NULLs: Allowed 30. COUNTRY Physical data type: char(3) AllowNULLs: Not Allowed 31. PHONE Physical data type: Phone Allow NULLs:Allowed 32. FAX Physical data type: Phone Allow NULLs: Allowed 33. EMAILPhysical data type: email Allow NULLs: Allowed 34. BACKPHONE Physicaldata type: Phone Allow NULLs: Allowed 35. BACKFAX Physical data type:Phone Allow NULLs: Allowed 36. BACKEMAIL Physical data type: email AllowNULLs: Allowed 37. WPAYNA1 Physical data type: varchar(35) Allow NULLs:Allowed 38. WPAYNA2 Physical data type: varchar(35) Allow NULLs: Allowed39. WPAYNA3 Physical data type: varchar(35) Allow NULLs: Allowed 40.WPAYNA4 Physical data type: varchar(35) Allow NULLs: Allowed 41.COMMENTS Physical data type: varchar(80) Allow NULLs: Allowed Codedetails 1. CK BANKACTIVITY ADD3 Type: Check clause Code body: ([ADD3] isnull and [ADD2] is not null or [ADD3] is null and [ADD2] is null) 2. CKBANKACTIVITY ADD4 Type: Check clause Code body: ([ADD4] is null and[ADD3] is not null or [ADD4] is null and [ADD3] is null) 3. CheckactionsType: Trigger Code body: CREATE TRIGGER Checkactions ON dbo.BANKACTIVITYFOR INSERT AS insert bankprofile select bankrtn, bankname,createdate=getdate( ),lastupdate=getdate( ),epnflag, chipsflag,chipsaba, chipslinkrtn,chipsdda,chipsdepth,banktype,add1,add2,add3,add4,city,state,zip,country,phone,fax,email,backphone,backfax,backemail,wpayna1,wpayna2,wpayna3,wpayna4 from inserted where actions=1 Indexdetails IX BANKACTIVITY BANKRTN Column(s): BANKRTN (Asc) Unique: NoExtended attributes: OnFileGroup F1 CLUSTERED No IGNORE_DUP_KEY NoFILLFACTOR 0 PAD_INDEX No DROP_EXISTING No STATISTICS_NORECOMPUTE NoForeign key details (child) Definition: Child Parent FK BANKACTIVITYACCOUNTSTATUS EPN EPNFLAG ACCOUNTSTATUS.STATUSID Relationship type:Non-Identifying Cardinality: One-to-Zero-or-More Allow NULLs: Notallowed Verb phrase: is of Ref. Integrity on update: No action Ref.Integrity on delete: No action FK BANKACTIVITY ACCOUNTSTATUS CHIPSCHIPSFLAG ACCOUNTSTATUS.STATUSID Relationship type: Non-IdentifyingCardinality: One-to-Zero-or-More Allow NULLs: Not allowed Verb phrase:hasFK_BANKACTIVITY_ACCOUNTSTATUS_CHIPS Inverse phrase: is of Ref.Integrity on update: No action Ref. Integrity on delete: No action FKBANKACTIVITY ACTIVITYDSP ACTIVITYDISP ACTIVITYDISP.DISPID Relationshiptype: Non-Identifying Cardinality: One-to-Zero-or-More Allow NULLs: Notallowed Verb phrase: hasFK_BANKACTIVITY_ACTIVITYDISP Inverse phrase: isof Ref. Integrity on update: No action Ref. Integrity on delete: Noaction FK BANKACTIVITY ACTIVITYSTATUS CHIPS ACTIVITYDISPACTIVITYDISP.DISPID Relationship type: Non-Identifying Cardinality:One-to-Zero-or-More Allow NULLs: Not allowed Verb phrase:hasFK_BANKACTIVITY_ACTIVITYDISP Inverse phrase: is of Ref. Integrity onupdate: No action Ref. Integrity on delete: No action FK BANKACTIVITYACTIVITYSTATUS ACTIVITYSTATUS ACTIVITYSTATUS.DISPID Relationship type:Non-Identifying Cardinality: One-to-Zero-or-More Allow NULLs: Notallowed Verb phrase: hasFK_BANKACTIVITY_ACTIVITYSTATUS Inverse phrase:is of Ref. Integrity on update: No action Ref. Integrity on delete: Noaction FK BANKACTIVITY BANKACTION ACTIONS BANKACTION.ACTIONIDRelationship type: Non-Identifying Cardinality: One-to-Zero-or-MoreAllow NULLs: Not allowed Verb phrase: hasFK_BANKACTIVITY_BANKACTIONInverse phrase: is of Ref. Integrity on update: No action Ref. Integrityon delete: No action FK BANKACTIVITY SOURCE CREATESOURCE SOURCE.SOURCEIDRelationship type: Non-Identifying Cardinality: One-to-Zero-or-MoreAllow NULLs: Not allowed Verb phrase: hasFK_BANKACTIVITY_SOURCE Inversephrase: is of Ref. Integrity on update: No action Ref. Integrity ondelete: No action CREATESOURCE SOURCE.SOURCEID Relationship type:Non-Identifying Cardinality: One-to-Zero-or-More Allow NULLs: Notallowed Verb phrase: hasFK_BANKACTIVITY_SOURCE Inverse phrase: is ofRef. Integrity on update: No action Ref. Integrity on delete: No actionBANKPROFILE Owner: dbo Target DB name: icns Number of columns: 29 Numberof Indexes:  0 Number of foreign keys:  3 Codes:  3 Type: Table Userdefined types: Name Data Type BANKRTN CHIPSABA BANKRTN N-Signed IntegerPhone N-Signed Integer Phone N-Signed Integer email C-VariableLength(32) Phone C-Variable Length(32) Phone C-Variable Length(32) emailC-Variable Length(128) C-Variable Length(32) C-Variable Length(128)C-Variable Length(32) C-Variable Length(32) C-Variable Length(128)Extended Attributes: OnFileGroup F1 Clustered PK No Columns Data TypeAllow NULLS Value/Range BANKRTN BANKRTN Not allowed BANKNAME varchar(96)Not allowed CREATEDATE datetime Not allowed LASTUPDT datetime Notallowed STATUS (FK) tinyint Not allowed EPNFLAG tinyint Not allowedCHIPSFLAG (FK) tinyint Not allowed CHIPSABA chipsaba AllowedCHIPSLINKRTN bankrtn Allowed CHIPSDDA varchar(34) Allowed CHIPSDEPTHtinylint Allowed ADD1 varchar(64) Not allowed ADD2 varchar(64) AllowedADD3 varchar(64) Allowed ADD4 varchar(64) Allowed CITY varchar(32)Allowed STATE varchar(32) Allowed ZIP varchar(11) Allowed COUNTRYchar(3) Not allowed PHONE Phone Allowed FAX Phone Allowed EMAIL emailAllowed BACKPHONE Phone Allowed BACKFAX Phone Allowed BACKEMAIL emailAllowed WPAYNA1 varchar(35) Allowed WPAYNA2 varchar(35) Allowed WPAYNA3varchar(35) Allowed WPAYNA4 varchar(35) Allowed Foreign keys ChildParent FK_BANKPROFILE_ACCOUNTSTATUS_EPM EPNFLAG ACCOUNT.STATUSIDFK_BANKPROFILE_ACCOUNTSTATUS_CHIPS CHIPSFLAG ACCOUNT.STATUSIDFK_BANKPROFILE_BANKSTATUS STATUS BANKSTATUS.STATUSIDFK_BANKROUTING_BANKPROFILE BANROUT.LINKEDRTN BANKRTN Column details 1.BANKRTN Physical data type: BANKRTN Allow NULLs: Not allowed 2. BANKNAMEPhysical data type: varchar(96) Allow NULLs Not allowed 3. CREATDATEPhysical data type: datetime Allow NULLs Not allowed Default value:getdate( ) 4. LASTUPDT Physical data type: datetime Allow NULLs Notallowed Default value: getdate( ) 5. STATUS (FK) Physical data type:tinyint Allow NULLs Not allowed 6. EPNFLAG (FK) Physical data type:tinyint Allow NULLs Not allowed 7. CHIPSFLAG (FK) Physical data type:tinyint Allow NULLs Not allowed 8. CHIPSABA Physical data type: CHIPSABAAllow NULLs Allowed 9. CHIPSLINKRTN Physical data type: BANKRTN AllowNULLs Allowed 10. CHIPSDDA Physical data type: varchar(34) Allow NULLsAllowed 11. CHIPSDEPTH Physical data type: tinyint Allow NULLs Allowed12. ADD1 Physical data type: varchar(64) Allow NULLs Not allowed 13.ADD2 Physical data type: varchar(64) Allow NULLs Allowed 14. ADD3Physical data type: varchar(64) Allow NULLs Allowed 15. ADD4 Physicaldata type: varchar(64) Allow NULLs Allowed 16. CITY Physical data type:varchar(32) Allow NULLs Allowed 17. STATE Physical data type:varchar(32) Allow NULLs Allowed 18. ZIP Physical data type: varchar(11)Allow NULLs Allowed 19. COUNTRY Physical data type: char(3) Allow NULLsNot allowed 20. PHONE Physical data type: Phone Allow NULLs Allowed 21.FAX Physical data type: Phone Allow NULLs Allowed 22. EMAIL Physicaldata type: email Allow NULLs Allowed 23. BACKPHONE Physical data type:Phone Allow NULLs Allowed 24. BACKFAX Physical data type: Phone AllowNULLs Allowed 25. BACKEMAIL Physical data type: email Allow NULLsAllowed 26. WPAYNA1 Physical data type: varchar(35) Allow NULLs Allowed27. WPAYNA2 Physical data type: varchar(35) Allow NULLs Allowed 28.WPAYNA3 Physical data type: varchar(35) Allow NULLs Allowed 29. WPAYNA4Physical data type: varchar(35) Allow NULLs Allowed Code details 1. CKBANK ADD3 Type: Check clause Code body: ([ADD3] is null and [ADD2] isnot or [ADD3] is null [ADD2] is null) 2. CK BANK ADD4 Type: Check clauseCode body: ([ADD4] is null and [ADD3] is not null or [ADD4] is null and[ADD3] is null) 3. NoModify Bank Type: Trigger Code body: CREATE TRIGGERNoModifyBank ON [dbo]. [BankProfile] INSTEAD OF INSERT, UPDATE, DELETEAS Raiserror(“Direct modification to this table is not allowed”, 16, 1)Foreign key details (child) Definition: Child Parent FK BANKPROFILEACCOUNTSTATUS EPN EPNFLAG ACCOUSTATUS.STATUSID Relationship type:Non-Identifying Cardinality: One-to-Zero-or-More Allow NULLs: Notallowed Verb phrase: has FK_BANKPROFILE_ACCOUNTSTATUS_EPN Inversephrase: is of Ref. Integrity on update; No action Ref. Integrity ondelete: No action FK BANKPROFILE ACCOUNTSTATUS CHIPS CHIPSFLAGACCOUSTATUS.STATUSID Relationship type: Non-Identifying Cardinality:One-to-Zero-or-More Allow NULLs: Not allowed Verb phrase: hasFK_BANKPROFILE_ACCOUNTSTATUS_CHIPS Inverse phrase: is of Ref. Integrityon update; No action Ref. Integrity on delete: No action FK BANKPROFILEBANKSTATUS STATUS BANKSTATUS.STATUSID Relationship type: Non-IdentifyingCardinality: One-to-Zero-or-More Allow NULLs: Not allowed Verb phrase:has FK_BANKPROFILE_BANKSTATUS Inverse phrase: is of Ref. Integrity onupdate; No action Ref. Integrity on delete: No action BANKROUTING Owner:dbo Target DB name: icns Number of columns: 2 Number of indexes: 0Number of foreign keys: 1 Codes: 0 Type: Table User defined types: NameData Type BANKRTN N-Signed Integer BANKRTN N-Signed Integer Extendedattributes: OnFileGroup PRIMARY Clustered PK Yes Columns Data Type AllowNULLS Value/Range BANKRTN BANKRTN Not allowed LINKEDRTN (FK) BANKRTN Notallowed Foreign keys Child Parent FK_BANKROUTING_BANKPROFILE LINKEDRTNBANKPROFILE.BANKRTN FK_PICACTIVITY_BANKROUTING PICACITIVITY.BANKRTNBANKRTN Column details 1. BANKRTN Physical data type: BANKRTN AllowNULLs: Not allowed 2. LINKEDRTN (FK) Physical data type: BANKRTN AllowNULLS: Not allowed Foreign key details (child) FK BANKROUTINGBANKPROFILE Definition: Child Parent LINKEDRTN BANKPROFILE.BANKRTNRelationship type: Non-Identifying Cardinality: One-to-Zero-or-MoreAllow NULLs: Not allowed Verb phrase: hasFK_BANKROUTING_BANKPROFILEInverse phrase: is of Ref. Integrity on update: No action Ref. Integrityon delete: No action BANKSTATUS Owner: dbo Target DB name: icns Numberof columns: 2 Number of indexes: 0 Number of foreign keys: 0 Codes: 0Type: Table Extended attributes: OnFileGroup PRIMARY Clustered PK YesColumns Data Type Allow NULLS Value/Range STATUS tinyint Not allowedDESCRIPTION varchar(50) Not allowed Foreign keys Child ParentFK_BANKPROFILE_BANKSTATUS BANKPROFILE.STATUS STATUSID Column details 1.STATUSID Physical data type: tinyint Allow NULLs: Not allowed 2.DESCRIPTION Physical data type: varchar(50) Allow NULLs Not allowedSOURCE Owner: dbo Target DB name: icns Number of columns: 2 Number ofIndexes: 0 Number of foreign keys: 0 Codes: 0 Type: Table ExtendedAttributes: OnFileGroup PRIMARY Clustered PK Yes Columns Data Type AllowNULLS Value/Range SOURCEID tinyint Not allowed DESCRIPTION varchar(30)Not allowed Foreign keys Child Parent FK_BANKACTIVITY-SOURCEBANKACTIVITY.CREATESOURCE SOURCEID FK_PICACTIVITY_SOURCEPICACTIVITY.CREATESOURCE SSOURCEID Column details 1. SOURCEID Physicaldata type: tinyint Allow NULLs: Not allowed 2. DESCRIPTION Physical datatype: varchar(30) Allow NULLs: Not allowed SYSTEMPARA Owner: dbo TargetDB name: icns Number of columns: 2 Number of indexes: 0 Number offoreign keys: 0 Codes: 0 Type: Table Extended attributes: OnFileGroupPRIMARY Clustered PK No Columns Data type Allow NULLs Value/RangePICDIGITS tinyint Not allowed PICSPEND int Not allowed Column details 1.PICDIGITS Physical data type: tinyint Allow NULLs: Not allowed 2.PICSPEND Physical data type: int Allow NULLs: Not allowed PIC Owner: dboTarget DB name: icns Number of columns: 31 Number of Indexes:  1 Numberof foreign keys:  3 Codes:  3 Type: Table User defined types: Name DataType PICTYPE C-Variable Length(17) BANKRTN N-Signed Integer PICTYPEC-Variable Length(17) BANKRTN N-Signed Integer Phone C-VariableLength(32) Extended attributes: OnFileGroup F1 Clustered PK No ColumnsData Type Allow NULLS Value/Range PICID PICTYPE Not allowed PICSTATUS(FK) tinyint Not allowed EPNFLAG (FK) tinyint Not allowed CHIPSFLAG (FK)tinyint Not allowed BANKRTN (I1) BANKRTIN Not allowed MASTERPIC PICTYPEAllowed PICDDASIZE tinyint Not allowed PICDDA varchar(34) Not allowedCHIPSABA smallint Allowed CHIPSLINKRTN BANKRTN Allowed CORPNAMEvarchar(96( Not allowed ADD1 varchar(64) Not allowed ADD2 varchar(64)Allowed ADD3 varchar(64) Allowed ADD4 varchar(64) Allowed CITYvarchar(32) Allowed STATE varchar(32) Allowed ZIP varchar(32 AllowedCOUNTRY char(3) Not allowed PHONE Phone Allowed SICBCODE smallintAllowed DUNSID varchar(10) Allowed BICCODE int Allowed BEICODE smallintAllowed TAXID int Allowed WPAYNA1 varchar(35) Allowed WPAYNA2varchar(35) Allowed WPAYNA3 varchar(35) Allowed WPAYNA4 varchar(35)Allowed CREATDATE datetime Not allowed LASTUPDT datetime Not allowedIndexes Columns Sort order IX_PIC_BANKRTN (I1) BANKRTN Ascending Foreignkeys Child Parent FK_BANKACCOUNT STATUS_EPN EPNFLAG PICACCOUNTSTATUSIDFK_PIC_PICACCOUNTSTATUS_CHIPS CHIPSFLAG PICACCOUNTSTATUSIDFK_PIC_PICSTATUS PICSTATUS PICSTATUS.PICSTATUSID Column details 1. PICIDPhysical data type: PICTYPE Allow NULLs: Not allowed 2. PICSTATUS (FK)Physical data type: tinyint Allow NULLs: Not allowed 3. EPNFLAG (FK)Physical data type: tinyint Allow NULLs: Not allowed 4. CHIPSFLAG (FK)Physical data type: tinyint Allow NULLs: Not allowed 5. BANKRTN (FK)Physical data type: BANKRTN Allow NULLs: Not allowed 6. MASTERRPICPhysical data type: PICTYPE Allow NULLs: Allowed 7. PICDDASIZ Physicaldata type: tinyint Allow NULLs: Not allowed 8. PICDDA Physical datatype: varchar(34) Allow NULLs: Not allowed 9. CHIPSABA Physical datatype: smallint Allow NULLs: Allowed Default value: 0 10. CHIPSLINKRTNPhysical data type: BANKRTN Allow NULLs: Allowed 11. CORPNAME Physicaldata type: varchar(96) Allow NULLs: Not allowed 12. ADD1 Physical datatype: varchar(64) Allow NULLs: Not allowed 13. ADD2 Physical data type:varchar(64) Allow NULLs: Not allowed 14. ADD3 Physical data type:varchar(64) Allow NULLs: Not allowed 15. ADD4 Physical data type:varchar(64) Allow NULLs: Allowed 16. CITY Physical data type:varchar(32) Allow NULLs: Allowed 17. STATE Physical data type:varchar(32) Allow NULLs: Not allowed 18. ZIP Physical data type:varchar(32) Allow NULLs: Allowed 19. COUNTY Physical data type: char(3)Allow NULLs: Not allowed 20. PHONE Physical data type: Phone AllowNULLs: Allowed 21. SICBCODE Physical data type: Samallint Allow NULLs:Allowed 22. DUNSID Physical data type: varchar(10) Allow NULLs: Allowed23. BICCODE Physical data type: int Allow NULLs: Allowed 24. BICCODEPhysical data type: smallint Allow NULLs: Allowed 25. TAXID Physicaldata type: int Allow NULLs: Allowed 26. WPAYNA1 Physical data type:varchar(35) Allow NULLs: Allowed 27. WPAYNA2 Physical data type:varchar(35) Allow NULLs: Allowed 28. WPAYNA3 Physical data type:varchar(35) Allow NULLs: Allowed 29. WPAYNA4 Physical data type:varchar(35) Allow NULLs: Allowed 30. CREATDATE Physical data type:datetime Allow NULLs: Not allowed Default value: getdate( ) 31. LASTUPDTPhysical data type: datetime Allow NULLs: Not allowed Default value:getdate( ) Code details 1. CK CORP ADD3 Type: Check clause Code body:([ADD3] is null and [ADD2] is not null or [ADD3] is null and [ADD2 isnull) 2. CK CORP ADD4 Type: Check clause Code body: ([ADD4] is null and[ADD3] is not null or [ADD4] is null and [ADD3] is null) 3. NoModifyPICType: Trigger Code body: CREATE TRIGGER NoModifyPIC ON [dbo].[PIC]INSTEAD OF INSERT, UPDATE, DELETE AS Raiserror(‘Direct modification tothis table is not allowed’, 16,1) Index details IX PIC BANKRTN BANKRTN(Asc) Column(s): Unique: No Extended attributes: OnFileGroup F2CLUSTERED No IGNORE_DUP_KEY No FILLFACTOR 0 PAD_INDEX No DROP_EXISTINGNo STATISTICS_NORECOMPUTE No Foreign key details (child) Definition:Child Parent FK PIC PICACCOUNTSTATUS EPN EPNFLAGPICACCOUNTSTATUS.STATUSID Relationship type: Non-IdentifyingCardinality: One-to Zero-or-More Allow NULLs: Not allowed Verb phrase:hasFK_PIC_PICACCOUNTSTATUS_EPN Inverse phrase: is of Ref. Integrity onupdate: No action Ref. Integrity on delete: No action FK PICPICACCOUNTSTATUS CHIPS CHIPSFLAG PICACCOUNTSTATUS.STATUSID Relationshiptype: Non-Identifying Cardinality: One-to-Zero-or-More Allow NULLs: Notallowed Verb phrase: hasFK_PIC_PICACCOUNTSTATUS_CHIPS Inverse phrase: isof Ref. Integrity on update: No action Ref. Integrity on delete: Noaction FK PIC PICSTATUS PICSTATUS PICSTATUS.PICSTATUSID Relationshiptype: Non-Identifying Cardinality: One-to-Zero-or-More Allow NULLs: Notallowed Verb phrase: hasFK_PIC_PICSTATUS Inverse phrase: is of Ref.Integrity on update: No action Ref. Integrity on delete: No actionPICACCOUNTSTATUS Owner: dbo Target DB name: icns Number of columns: 2Number of Indexes: 0 Number of foreign keys: 0 Codes: 0 Type: TableExtended Attributes: OnFileGroup PRIMARY Clustered PK Yes Columns DataType Allow NULLS Value/Range STATUSID tinyint Not allowed DESCRIPTIONvarchar(20) Not allowed Foreign keys Child ParentFK_PIC_PICACCOUNTSTATUS_EPN PIC.EPNFLAG STATUSIDFK_PICACCOUNTSTATUS_CHIPS PIC.CHIPSFLAG STATUSIDFK_PICACTIVITY_PICACCOUNTSTATUS_EPN PICACITIVITY.EPNFLAG STATUSIDFK_PICACTIVITY_PICACCOUNTSTATUS_CHIPS PICACTIVITY.CHIPSFLAG STATUSIDColumn details 1. STATUSID Physical data type: tinyint Allow NULLs: Notallowed 2. DESCRIPTION Physical data type: varchar(20) Allow NULLs: Notallowed PICACTION Owner: dbo Target DB name: icns Number of columns: 2Number of Indexes: 0 Number of foreign keys: 0 Codes: 0 Type: TableExtended Attributes: OnFileGroup PRIMARY Clustered PK Yes Columns DataType Allow NULLS Value/Range ACTIONID tinyint Not allowed DESCRIPTIONvarchar(20) Not allowed Foreign keys Child ParentFK_PICACTIVITY_PICACTION PICACTIVITY.PICACTION ACTIONID Columndetails 1. ACTIONID Physical data type: tinyint Allow NULLs: Not allowed2. DESCRIPTION Physical data type: varchar(20) Allow NULLs: Not allowedPICACTIVITY Owner: dbo Target DB name: icns Number of columns: 41 Numberof Indexes:  2 Number of foreign keys:  7 Codes:  1 Type: Table Userdefined types: Name Data Type PICTYPE C-Variable Length(17) BANKRTNN-Signed Integer CHIPSABA N-Signed Integer BANKRTN N-signed IntegerPhone C-Variable Length(32) Extended attributes: OnFileGroup F2Clustered PK Yes Columns Data Type Allow NULLS Value/Range ACTIVITYIDInt Identity Not allowed ACTIVITYDISP (FK) tinyint Not allowed APPLDATEdatetime Allowed STATUS (FK) tinyint Not allowed CREATEDATE datetime Notallowed CREATEUSER varchar(40) Not allowed CREATESOURCE (FK) tinyintAllowed APPRDATE datetime Allowed APPRUSER varchar(40) AllowedCANCELDATE datetime Allowed CANCELUSER varchar(40) Allowed PICACTION(FK) tinyint Not allowed EFFDATE datetime Allowed PICID (12) PICTYPEAllowed EFFDATE tinyint Not allowed PICID (12) tinyint Not allowedEPNFLAG (FK) BANKRTN Not allowed CHIPSFLAG (FK) tinyint Not allowedBANKRTN (FK, I1) BANKRTN Not allowed PICDDASIZE tinyint Not allowedPICDDA varchar(34) Not allowed CHIPSABA CHIPSABA Allowed CHIPSRTNBANKRTN Allowed CORPNAME varchar(96) Not allowed ADD1 varchar(64) Notallowed ADD2 varchar(64) Allowed ADD3 varchar(64) Allowed ADD4varchar(64) Allowed CITY varchar(32) Allowed STATE varchar(32) AllowedZIP varchar(11) Allowed COUNTRY char(3) Not allowed PHONE phone AllowedSICBCODE char(10) Allowed DUNSID varchar(10) Allowed BICCODE int AllowedBEICODE smallint Allowed TAXID int Allowed WPAYNA1 varchar(35) AllowedWPAYNA2 varchar(35) Allowed WPAYNA3 varchar(35) Allowed WPAYNA4varchar(35) Allowed COMMENTS varchar(80) Allowed Indexes Columns Sortorder IX_PICACTIVITY_BANKRTN (I1) BANKRTN Ascending IX_PICACTIVITY_PICID(12) PICID Ascending Foreign keys Child ParentFK_PICACTIVITY_ACTIVITYDISP ACTIVITYDISP ACTIVITYDISP.DISPIDFK_PICACTIVITY_ACTIVITYSTATUS STATUS ACTIVITYSTATUS.STATUSIDFK_PICACTIVITY_BANKROUTING BANKRTN BANKROUTING.BANKRTNFK_PICACTIVITY_SOURCE CREATESOURCE SOURCE.SOURCEIDFK_PICACTIVITY_PICACCOUNTSTATUS_EPN EPNFLAG PICACCOUNTSTATUS.STATUSIDFK_PICACTIVITY_PICACCOUNTSTATUS_CHIPS CHIPSFLAGPICACCOUNTSTATUS.STATUSID FK_PICACTIVITY_PICACTION PICACTIONPICACTION.ACTIONID Column details 1. ACTIVITYID Physical data type: intidentity Allow NULLs: Not allowed 2. ACTIVITYDISP (FK) Physical datatype: tinyint Allow NULLs: Not allowed 3. APPLDATE Physical data type:datetime Allow NULLs: Allowed 4. STATUS (FK) Physical data type:tinytint Allow NULLs: Not allowed 5. CREATEDATE Physical data type:datetime Allow NULLs: Not allowed 6. CREATE USER Physical data type:varchar(40) Allow NULLs: Not allowed 7. CREATESOURCE (FK) Physical datatype: tinyint Allow NULLs: Allowed 8. APPRDATE Physical data type:datetime Allow NULLs: Allowed 9. APPRUSER Physical data type:varchar(40) Allow NULLs: Allowed 10. CANCELDATE Physical data type:datetime Allow NULLs: Allowed 11. CANCELUSER Physical data type:varchar(40) Allow NULLs: Allowed 12. PICACTION Physical data type:tinyint Allow NULLs: Not allowed 13. EFFDATE Physical data type:datetime Allow NULLs: Allowed Default value: getdate( ) + 1 14. PICID(12) Physical data type: PICTYPE Allow NULLs: Allowed 15. EPNFLAG (FK)Physical data type: tinyint Allow NULLs: Not allowed 16. CHIPSFLAG (FK)Physical data type: tinyint Allow NULLs: Not allowed 17. BANKRTN (FK,11) Physical data type: BANKRTN Allow NULLs: Not allowed 18. PICDDASIZEPhysical data type: tinyint Allow NULLs: Not allowed 19. PICDDA Physicaldata type: varchar(34) Allow NULLs: Not allowed 20. CHIPSABA Physicaldata type: CHIPSABA Allow NULLs: 0 Allowed 21. CHIPSRTN Physical datatype: BANKRTN Allow NULLs: Allowed 22. CORPNAME Physical data type:varchar(96) Allow NULLs: Not allowed 23. ADD1 Physical data type:varchar(64) Allow NULLs: Not allowed 24. ADD2 Physical data type:varchar(64) Allow NULLs: Allowed 25. ADD3 Physical data type:varchar(64) Allow NULLs: Allowed 26. ADD4 Physical data type:varchar(64) Allow NULLs: Allowed 27. CITY Physical data type:varchar(32) Allow NULLs: Allowed 28. STATE Physical data type:varchar(32) Allow NULLs: Allowed 29. ZIP Physical data type: varchar(11)Allow NULLs: Allowed 30. COUNTRY Physical data type: char(3) AllowNULLs: Not allowed 31. PHONE Physical data type: Phone Allow NULLs:Allowed 32. SICBCODE Physical data type: char(10) Allow NULLs: Allowed33. DUNSID Physical data type: varchar(10) Allow NULLs: Allowed 34.BICCODE Physical data type: int Allow NULLs: Allowed 35. BEICODEPhysical data type: smallint Allow NULLs: Allowed 36. TAXID Physicaldata type: int Allow NULLs: Allowed 37. WPAYNA1 Physical data type:varchar(35) Allow NULLs: Allowed 38. WPAYNA2 Physical data type:varchar(35) Allow NULLs: Allowed 39. WPAYNA3 Physical data type:varchar(35) Allow NULLs: Allowed 40. WPAYNA4 Physical data type:varchar(35) Allow NULLs: Allowed 41. COMMENTS Physical data type:varchar(80) Allow NULLs: Allowed Code details 1. AddPICActivity Type:Trigger Code body: CREATE trigger dbo.AddPICActivity on dbo.PICACTIVITYFor INSERT as declare @action int declare @PICID varchar (17) select@action=PICaction from inserted if(@action=2) if(notexists(selectu.PICID from PIC u,insertd i where i.PICID=u.PICID)) Begin raiserror(‘PICID not exists, Transaction is rolled back',16,1) ROLLBACK Endif(NULL=(select PICID from inserted) Begin Raiserror(‘PICID cannot beNULL’,16,1) ROLLBACK End if(@action=1) BEGIN exec PickPIC @ PICID OUTUpdate PIC Activity set PICID=@PICID from PICACTIVITY u, Inserted iwhere u.activityID=i.activityID insert PIC select@PICID,2,epnflag,chipsflag,bankrtn,null,PICDASIXE,PICDDA,CHIPSABA,CHIPSRTN,Corpname,Add1,Add2,Add4,City,State,Zip,Country,Phone,SICBCODE,DUNSID,BICCODE,BEICODE,TAXID,WPAYNA1,WPA

NA2,WPAYNA3,WPAYNA4,Getdate( ),Getdate( ) from Inserted End Indexdetails IX PICACTIVITY BANKTRN Columns(s) BANKRPTN (Asc) Unique: NoExtended attributes OnFileGroup F1 CLUSTERED No IGNORE_DUP_KEY NoFILLFACTOR 0 PAD_INDEX No DROP_EXISTING No STATISTICS_NORECOMPUTE No IXPICACTIVITY PICID Column(s) PICID (Asc) Unique: No Extended attributesOnFileGroup F1 CLUSTERED No IGNORE_DUP_KEY No FILLFACTOR 0 PAD_INDEX NoDROP_EXISTING No STATISTICS_NORECOMPUTE No Foreign key details (child)Definition Child Parent FX PICACTIVITY ACTIVITYDISP ACTIVITYDISPACTIVITYDISP.DISPID Relationship type: Non-Identifying CardinalityOne-to-Zero-or-More Allow NULLs: Not allowed Verb phrase:hasFK_PICACTIVITY_ACTIVITYDISP Inverse phrase: is of Ref. Integrity onupdate: No action Ref. Integrity on delete: No action FX PICACTIVITYACTIVITYSTATUS STATUS ACTIVITYSTATUS-STATUSID Relationship type:Non-Identifying Cardinality One-to-Zero-or-More Allow NULLs: Not allowedVerb phrase: hasFK_PICACTIVITY_ACTIVITYSTATUS Inverse phrase: is of Ref.Integrity on update: No action Ref. Integrity on delete: No action FKPICACTIVITY BANKROUTING BANKRTN BANKROUTING.BANKRTN Relationship type:Non-Identifying Cardinality One-to-Zero-or-More Allow NULLs: Not allowedVerb phrase: hasFK_PICACTIVITY_BANKROUTING Inverse phrase: is of Ref.Integrity on update: No action Ref. Integrity on delete: No action FKPICACTIVITY SOURCE CREATESOURCE SOURCE.SOURCEID Relationship type:Non-Identifying Cardinality Zero-or-One-to-Zero-or-More Allow NULLs:Allowed Verb phrase: hasFK_PICACTIVITY_SOURCE Inverse phrase: is of Ref.Integrity on update: No action Ref. Integrity on delete: No action FKPICACTIVITY PICACCOUNTSTATUS.EPN EPNFLAG PICACCOUNTSTATUS.STATUSIDRelationship type: Non-Identifying Cardinality One-to-Zero-or-More AllowNULLs: Not allowed Verb phrase: hasFK_PICACTIVITY_PICACCOUNTSTATUS-EPNInverse phrase: is of Ref. Integrity on update: No action Ref. Integrityon delete: No action FK PICACTIVITY PICACCOUNTSTATUS CHIPS CHIPSFLAGPICACCOUNTSTATUS.STATUSID Relationship type: Non-Identifying CardinalityOne-to-Zero-or-More Allow NULLs: Not allowed Verb phrase:hasFK_PICACTIVITY_ACCOUNTSTATUS.CHIPS Inverse phrase: is of Ref.Integrity on update: No action Ref. Integrity on delete: No action FKPICACTIVITY PICACTION PICACTION PICACTION.ACTIONID Relationship type:Non-Identifying Cardinality One-to-Zero-or-More Allow NULLs: Not allowedVerb phrase: hasFK_PICACTIVITY_PICACTION Inverse phrase: is of Ref.Integrity on update: No action Ref. Integrity on delete: No action PICSOwner: dbo Target DB name: icns Number of columns: 1 Number of Indexes:0 Number of foreign keys: 0 Codes: 1 Type: Table User defined types:Name Data Type PICTYPE C-Variable Length(17) Extended attributes:OnFileGroup PRIMARY Clustered PK No Columns Data type Allow NULLSValue/Range PICID PICTYPE Not allowed Column details 1. PICID Physicaldata type: PICTYPE Allow NULLs: Not allowed Code details 1. UPDATESYPARAType: Trigger Code body: CREATE TRIGGER DBO UPDATESYSPARA [dbo].[PICS]FOR INSERT AS UPDATE SYSTEMPARA SET PICDIGITS-8, PICSPEND=(SELECTCOUNT(*)FROM pics) PICS Owner: dbo Target DB name: icns Number ofcolumns: 2 Number of Indexes: 0 Number of foreign keys: 0 Codes: 0 Type:Table Extended attributes: OnFileGroup PRIMARY Clustered PK Yes ColumnsData type Allow NULLs Value/Range PICSTATUSID tinyint Not allowedDESCRIPTION varcher(30) Not allowed Foreign keys Child ParentFK_PIC_PICSTATUS PIC.PICSTATUS PICSTATUSID Column details 1. PICSTATUSIDPhysical data type: tinyint Allow NULLs: Not allowed 2. DESCIPTIONPhysical data type: varchar(30) Allow NULLs: Not allowed

indicates data missing or illegible when filed

The following is a list of application components associated with thePIC database. The list also shows functions associated with eachcomponent. This list is for illustrative purposes only.

PIC

-   -   Add PIC        -   Input: PIC table fields, Initial Status of Activity record            (approved or proposed)        -   Output: PIC number or error number, Activity ID number        -   Process: Ensure no PIC record and no PIC Activity record            already exists for PIC. If no problems encountered, add an            activity record to the PIC Activity table. If initial status            is approved, assign PIC number and add record to PIC table            as inactive. The PIC number will become active when the            apply activity program is run for the PIC number's effective            date.    -   Modify PIC        -   Input: PIC table fields, Initial Status of Activity record        -   Output: Error message if unsuccessful, Activity ID number        -   Process: If no problems exist, add activity record    -   Transfer PIC        -   Input: Required fields as indicated in business plan        -   Output: Error message if unsuccessful        -   Process: If no problems exist, add activity record.    -   Inquiry by DDA/RT (Demand Deposit Account/Routing Number)        -   Input: DDA number and RT        -   Output: A list of PIC records matching the input    -   Inquiry by PIC        -   Input: PIC number        -   Output: PIC record if found    -   Inquiry by Name        -   Input: Name and/or address fields, routing number        -   Output: List of possible matches        -   Process: Only allow inquiry into PICs belonging to the            requesting bank    -   PIC Activity        -   Change Status of existing Activity            -   Input: Activity ID, New Status (approved, cancelled,                applied etc.)            -   Output: Error message if unsuccessful        -   Inquire by Activity Request Number            -   Input: Activity ID            -   Output: Activity record        -   Inquire on all Activity in Proposed state for a bank            -   Input: Routing Number            -   Output: List of all proposed activity records        -   Inquire on all activity (closed and open) by a PIC number            -   Input: Routing Number, PIC number            -   Output: List of all activity records for PIC number            -   Process: Should not include activity records for that                PIC number that were made by another bank in the case of                a PIC that has gone through a transfer    -   Bank Profile        -   Add Bank Profile Record            -   Input: All Bank Profile fields            -   Output: Error message if unsuccessful            -   Process: Set status to initialized so the first time a                bank signs on to the web site it verifies all data, then                set flag to active        -   Modify Bank Profile Record            -   Input: All Bank Profile fields            -   Output: Error message if unsuccessful            -   Process: If no problems encountered, add an activity                record to the Bank Profile Activity table.        -   Routing Number Table            -   Add routing number entry for a Master routing number                -   Input Bank Routing Number, Master Bank Routing                    Number                -   Output: Error Message if unsuccessful            -   Delete routing number entry from a Master routing number                -   Input: Bank Routing Number, Master Bank Routing                    Number                -   Output: Error Message if unsuccessful        -   Bank Profile Activity            -   Inquire by an RT number for all prior activity records                -   Input: Bank Routing Number, Master Bank Routing                    Number                -   Output: List of activity records            -   Users            -   Retrieve user info via active directory call            -   Add user via active directory call            -   Modify user attributes via active directory call        -   Create program or use SQL (Structured Query Language)            utility to apply and create a file of today's PIC and bank            profile activity effective for the next business day and            send this tile to the CHIPS and EPN mainframes.        -   Create program to process an incoming file from a bank and            generate an outbound file. This will call the appropriate            functions within the appropriate components above such as            the Add PIC function. Each component needs to have functions            for inquiring, adding, modifying and deleting records. (No            delete is required for PICs

For illustrative purposes, a number of PIC processes are depicted intabular form in Tables 2 through 5. Each table provides the Name, Type,and Size of the Field, and depending on the type of process beingperformed whether the field is input/output of the process (X), anoptional input/output (O), only displayed (D), or the result of theprocess (R).

Also, for illustrative purposes, the following is a list of potentialbusiness facade routines and business rules routines associated with thePIC database.

Business Facade Routines for PIC

GetPICbyPIC

Description: Get one the PICs with the specified PIC belonging to theUser's RT. If a date is specified, show the historical representationfor the requested date.

Parameters:

-   -   PIC number    -   Routing Transit Number    -   Date (optional—only supply if looking for a specific date).

Output: PIC Dataset

GetPICbyDDART

Description: Get one or more PICs with the specified DDA/RT belonging tothe User's RT. If a date is specified, show the historicalrepresentation for the requested date.

Parameters:

-   -   DDA Number    -   Routing Number    -   User's Routing Number    -   Date (optional—only supply if looking for a specific date).

Output: Owner Flag: 1 if the PIC number belongs to user's bank PIC Datastructure

TABLE 2 PIC ACCOUNT PROCESS PIC ACCOUNT PIC ACCOUNT TYPE SZ ISSUE PICMAINTAIN (MODIFY) TRANSFER INVESTIGATIONS (INQUIRY) PIC IDENTIFIER AN 17R D D D PIC GLOBAL STATUS N  1 X X D EPN ACCOUNT STATUS N  2 X X D CHIPSACCOUNT STATUS N  2 X X D BANK RT NUMBER N  9 X X X D PIC DDA SIZE N  2X X X D PIC DDA AN 34 X X X D PIC CHIPS BANK ABA N  4 O O O D CHIPS LINKRT NUMBER N  9 O O O D PIC BANK CATEGORY N  2 O O D CORPORATE NAME ANS96 X X D ADDRESS 1 ANS 64 X X D ADDRESS 2 ANS 64 O O D ADDRESS 3 ANS 64O O D ADDRESS 4 ANS 64 O O D CITY ANS 32 O O D STATE/PROV ANS 32 O O DPOSTAL CODE AN 11 O O D COUNTRY ANS  3 X X D PHONE NUMBER AN 32 O O DSIC BUSINESS CODE N  4 O O D DUNS ID AN 10 O O D BIC CODE N 11 O O D BEICODE N  6? O O D TAX ID N 12 O O D WIRE PAY N/A 1 ANS 35 O O D WIRE PAYN/A 2 ANS 35 O O D WIRE PAY N/A 3 ANS 35 O O D WIRE PAY N/A 4 ANS 35 O OD CREATION DATETIME N 14 R D D LAST UPDATE DATETIME N 14 R R D X—I/O ofProcess O—Optimal I/O D—Display Only R—Result of Process

TABLE 3 PIC ACTIVITY PROCESS PIC ACTIVITY ISSUE MODIFY TRANSFER ACTIVITYAPPROVE REVISE CANCEL FIELD NAME TYPE SZ PIC PIC PIC INQUIRY ACTIVITYACTIVITY ACTIVITY ACTIVITY ID N 12 R R R D D D D ACTIVITY N  1 R R R D DR R DISPOSITION APPLIED DATETIME N 14 D ACTIVITY STATUS N  2 R R R D R RR CREATION DATETIME N 14 R R R D D D D CREATED BY USER AN 40 R R R D D DD APPROVAL N 14 D R DATETIME APPROVED BY USER AN 40 D R CANCELLED N 14 DR R DATETIME CANCELLED BY USER AN 40 D R R PIC DETAIL ACTION AN  6 R R RD D X D PIC IDENTIFIER AN 17 R R R D D X D UPDATE EFFECTIVE N  8 R R D DO D DATE EPN ACCOUNT N  2 R R D D X D STATUS CHIPS ACCOUNT N  2 R R D DX D STATUS BANK RT NUMBER N  9 R R R D D X D PIC DDA SIZE N  2 R R R D DX D PIC DDA AN 34 R R R D D X D PIC CHIPS BANK ABA N  4 R R R D D O DCHIPS LINK RT N  9 R R R D D O D NUMBER PIC BANK CATEGORY N  2 R R D D OD CORPORATE NAME ANS 96 R R D D X D ADDRESS 1 ANS 64 R R D D X D ADDRESS2 ANS 64 R R D D O D ADDRESS 3 ANS 64 R R D D O D ADDRESS 4 ANS 64 R R DD O D CITY ANS 32 R R D D O D STATE/PROV ANS 32 R R D D O D POSTAL CODEAN 11 R R D D O D COUNTRY ANS  3 R R D D X D BIC CODE N 11 R R D D O DBEI CODE N  6? R R D D O D TAX ID N 12 R R D D O D WIRE PAY N/A  1 ANS35 R R D D O D WIRE PAY N/A  2 ANS 35 R R D D O D WIRE PAY N/A  3 ANS 35R R D D O D WIRE PAY N/A  4 ANS 35 R R D D O D COMMENTS R R R D D X—I/Oof Process O—Optimal I/O D—Display Only R—Result of Process

TABLE 4 BANK PROFILE PROCESS BANK PROFILE FIELD NAME TYPE SZ ADD BANKMODIFY PROFILE INVESTIGATIONS (INQUIRY) BANK ROUTING NUMBER N 9 X X DBANK STATUS N 1 X X D BANK NAME AN 96 X X D CREATION DATETIME N 14 R D DLAST UPDATE DATETIME N 14 R R D EPN FLAG N 1 X X D CHIPS FLAG N 1 X X DCHIPS BANK ABA N 4 O O D CHIPS LINK RT NUMBER N 9 O O D CHIPS DDA ACCTAN 34 O O D CHIPS CHAIN DEPTH N 1 O O D TYPE OF BANK AN 3 X X D ADDRESS1 ANS 64 X X D ADDRESS 2 ANS 64 O O D ADDRESS 3 ANS 64 O O D ADDRESS 4ANS 64 O O D CITY ANS 32 O O D STATE/PROV ANS 32 O O D POSTAL CODE AN 11O O D COUNTRY ANS 3 X X D PHONE NUMBER AN 32 O O D FAX NUMBER AN 32 O OD E-MAIL ADDRESS ANS 128 O O D BACKUP PHONE NUMBER AN 32 O O D BACKUPFAX NUMBER AN 32 O O D BACKUP E-MAIL ADDRESS ANS 128 O O D WIRE PAYN/A/4 ANS 35 O O D WIRE PAY N/A 2 ANS 35 O O D IRE PAY N/A 3 ANS 35 O OD WIRE PAY N/A 4 ANS 35 O O D X—I/O of Process O—Optimal I/O D—DisplayOnly R—Result of Process

TABLE 5 BANK PROFILE ACTIVITY PROCESS BANK PROFILE ACTIVITY ADD BANKMODIFY ACTIVITY APPROVE REVISE CANCEL FIELD NAME TYPE SZ PROFILE PROFILEINQUIRY ACTIVITY ACTIVITY ACTIVITY ACTIVITY ID N 12 R R D D D D ACTIVITYDISPOSITION N 1 R R D D R R ACTIVITY APPLIED DATETIME N 14 D ACTIVITYSTATUS N 2 R R D R R R ACTIVITY CREATION DATETIME N 14 R R D D D DCREATED BY USER AN 40 R R D D D D ACTIVITY APPROVAL DATETIME N 14 D RAPPROVED BY USER AN 40 D R ACTIVITY CANCELLED DATETIME N 14 D R RCANCELLED BY USER AN 40 D R R DETAIL ACTION N 1 R R D D X D UPDATEEFFECTIVE DATE N 8 R R D D X D BANK ROUTING NUMBER N 9 R R D D D D BANKSTATUS N 1 R R D D X D BANK NAME AN 96 R R D D X D CREATION DATETIME N14 R R D D D D LAST UPDATE DATETIME N 14 R R D D R D EPN FLAG N 1 R R DD X D CHIPS FLAG N 1 R R D D X D CHIPS BANK ABA N 4 R R D D O D CHIPSLINK RT NUMBER N 9 R R D D O D CHIPS DDA ACCT AN 34 R R D D O D CHIPSCHAIN DEPTH N 1 R R D D O D TYPE OF BANK AN 3 R R D D X D ADDRESS 1 ANS64 R R D D X D ADDRESS 2 ANS 64 R R D D O D ADDRESS 3 ANS 64 R R D D O DACTIVITY ID N 12 R R D D D D ADDRESS 4 ANS 64 R R D D O D CITY ANS 32 RR D D O D STATE/PROV ANS 32 R R D D O D POSTAL CODE AN 11 R R D D O DCOUNTRY ANS 3 R R D D X D PHONE NUMBER AN 32 R R D D O D FAX NUMBER AN32 R R D D O D E-MAIL ADDRESS ANS 128 R R D D O D BACKUP PHONE NUMBER AN32 R R D D O D BACKUP FAX NUMBER AN 32 R R D D O D BACKUP E-MAIL ADDRESSANS 128 R R D D O D WIRE PAY N/A 1 ANS 35 R R D D O D WIRE PAY N/A 2 ANS35 R R D D O D WIRE PAY N/A 3 ANS 35 R R D D O D WIRE PAY N/A 4 ANS 35 RR D D O D X—I/O of Process O—Optimal I/O D—Display Only R—Result ofProcess

GetPICbyCorpNameCity

Description: Get all PICs that begin with the Corporation. Name suppliedand restrict by the city name if supplied. No date is allowed for thissearch.

Parameters:

-   -   Corp Name    -   City Name

Output: PIC dataset of all PICs meeting the search

CreatePIC

Description: Create a PIC record. Sets up a PIC Dataset and calls thebusiness rules' insert PIC procedure which validates all fields passed.This routine is passed a flag saying whether this is just a validatecall or a validate and update call. Boolean procedure returning true ifsuccessful.

Parameters:

-   -   All PIC fields    -   Routing Number of User requesting the create    -   Update or Validate only

GetPICtoModify

Description: Gets a PIC record to modify. If PIC is valid, then itreturns the PIC data record from the PIC table. If open activity exists,the activity id is set to the activity ID of the pending activity.Boolean procedure returning true if successful.

Parameters:

-   -   PIC    -   Routing Number of User requesting the create    -   PICdata

UpdatePIC

Description: Modify a PIC record. Passes a PIC dataset to the businessrules' update PIC procedure which validates all fields passed. Thisroutine is passed a flag saying whether this is just a validate call, ora validate and update call. Boolean procedure returning true ifsuccessful.

Parameters:

-   -   All PIC fields in PIC dataset form    -   Update or Validate only

ClosePIC

Description: Changes the status of a PIC record to closed. Passes thePIC Dataset to the business rules' closethePIC procedure which validatesall fields passed. Boolean procedure returning true if successful.

Parameters:

-   -   PIC data

ReactivatePIC

Description: Changes the status of a closed PIC record to open. Passesthe PIC Dataset to the business rules' close PIC procedure whichvalidates all fields passed. Boolean procedure returning true ifsuccessful.

Parameters:

-   -   PIC data

ApproveActivity

Description: Changes the status of a proposed PIC activity record toapproved. Calls the business rules' approve PIC Activity procedure.Boolean procedure returning true if successful.

Parameters:

-   -   PIC data set including the activity ID number and the user name        approving the record

CancelActivity

Description: Changes the status of an open PIC activity record tocanceled. Calls the business rules' cancel PIC Activity procedure.Boolean procedure returning true if successful.

Parameters:

-   -   PIC data set including the activity ID number and the user name        approving the record.

TransferPIC

Description: Transfers a PIC from one bank to another. Calls thebusiness rules' transfer PIC procedure. Boolean procedure returning trueif successful.

Parameters:

-   -   PIC dataset including the PIC, Requesting User's RT, the new RT,        new DDA number and new TaxID

ContestTransfer

Description: Contests a PIC Transfer. Calls the business rules' contesttransfer procedure. Boolean procedure returning true if successful.

Parameters:

-   -   PIC data set including the activity ID number and user        contesting the transfer

Release Transfer

Description: Releases a PIC Transfer. Calls the business rules' releasetransfer procedure. Boolean procedure returning true if successful.

Parameters:

-   -   PIC dataset including the activity ID and the user releasing the        transfer

Business Facade Routines for URIC Activity

SearchActivitybyPIC

Description: Get all PIC activity for a given PIC. Routing number issupplied to ensure the PIC belongs to the requestor. If a date issupplied restrict the selection to be between the dates given.

Parameters:

-   -   PIC    -   Routing Transit Number    -   Optional Start Date    -   Optional End Date

Output: PIC dataset of all PIC activity records of activity records

SearchActivityByType

Description: Get all PIC activity for a bank based on the type ofactivity. Routing number is supplied to ensure the PIC belongs to therequestor. If a date is supplied restrict the selection to be betweenthe dates given.

Parameters:

-   -   Activity Type    -   Routing Transit Number    -   Optional Start Date

Optional End Date Output: PIC dataset of all URIC activity records ofactivity records

SearchActivityByStatus

Description: Get all PIC activity for a bank based on a given activitystatus. Routing number is supplied to ensure the PIC belongs to therequestor. If a date is supplied restrict the selection to be betweenthe dates given.

Parameters:

-   -   Activity Status    -   Routing Transit Number    -   Optional Start Date    -   Optional End Date

Output: URIC dataset of all PIC activity records of activity records

SearchActivitybyCorpName

Description: Get all PIC activity for a bank based on a company name.Routing number is supplied to ensure the PIC belongs to the requestor.If a date is supplied restrict the selection to be between the datesgiven.

Parameters:

-   -   Company Name    -   Routing Transit Number    -   Optional Start Date

Optional End Date Output: PIC dataset of all PIC activity records ofactivity records

SearchActivitybyUserName

Description: Get all PIC activity for a bank created by a specific user.Routing number is supplied to ensure the PIC belongs to the requestor.If a date is supplied restrict the selection to be between the datesgiven.

Parameters:

-   -   User Name    -   Routing Transit Number    -   Optional Start Date    -   Optional End Date

Output: PIC dataset of all PIC activity records of activity records

GetPICActivitybyID

Description: Get a specific PIC activity record

Parameters:

-   -   Activity ID Number

Output: PIC dataset of all PIC activity records of activity records

Business Rules Routines for PIC

Insert

Description: Validates all fields passed. If update is requested and alledits pass, the new PIC is createdBoolean procedure returning true ifsuccessful.

Validates the following

-   -   All fields for proper size and character type    -   DDA must be 17 characters or less if EPN enabled. If only CHIPS        enabled it can be up to 35    -   Must be either CHIPS enabled or EPN enabled    -   If bank is not CHIPS enabled, CHIPS enabled flag cannot be on    -   If bank is not EPN enabled, EPN enabled flag cannot be on    -   Cannot skip an address line    -   If CHIPS enabled, Wire pay name and address is required    -   Cannot skip a wire pay name and address line    -   Must be a valid business date. Cannot be less than the next        valid effective date (either tomorrow or the next day if the        update has already been run)    -   RTN must belong to the bank requesting    -   DDA/RT combination cannot already exist

Parameters:

-   -   All PIC fields via the PIC dataset    -   Routing Number of User requesting the create    -   Update or Validate only

Update

Description: Validates all fields passed. If validate only is requested,only validation is done. If all fields pass all edits and update isrequested, the PIC record is updated by creating an activity record.Boolean procedure returning true if successful.

Validates all the same as Insert with the following exceptions:

-   -   DA/RT can already exist    -   Must notify if open activity already exists for the PIC

Parameters:

-   -   All PIC fields via the PIC dataset    -   Update or Validate only

ClosethePIC

Description: Changes the status of a PIC record to closed. Validates theclose request. If passes the edits, calls the update data access routingto create an activity record with an action type of close. Booleanprocedure returning true if successful.

Parameters:

-   -   PIC data set

Validates: effective date for a valid business date

ReactivatethePIC

Description: Changes the status of a PIC record to open. Validates thereactivate request. If passes the edits, calls the update data accessrouting to create an activity record with an action type of reactivate.Boolean procedure returning true if successful.

Parameters:

-   -   PIC data set

Validates: effective date for a valid business date

ApproveActivity

Description: Changes the status of a proposed PIC activity record toapproved if validation is successful. Calls the data access UpdateStatus routine. Boolean procedure returning true if successful.

Parameters:

-   -   Activity ID Number

Validates: The user approving is not the user that entered the activity

CancelActivity

Description: Changes the status of an open PIC activity record tocanceled if the validation is successful. Calls the data access UpdateStatus routine. Boolean procedure returning true if successful.

Parameters:

-   -   Activity ID Number

Validates: The user canceling the activity is either the creator or anadministrator

TransferPIC

Description: Transfers a PIC from one bank to another if all validationsare successful. Boolean procedure returning true if successful.

Parameters:

-   -   PIC data as dataset

Validates:

-   -   Effective date is valid business date    -   Must be either EPN capable or CHIPS capable    -   Cannot be EPN capable if bank is not EPN capable    -   Cannot be CHIPS capable if bank is not CHIPS capable    -   DDA number must be alphanumeric    -   DDA number cannot exceed 17 characters if EPN capable

ContestTransfer

Description: Updates the PIC activity record with the status ofcontested. Callst the data access Update Status routine. Booleanprocedure returning true if successful.

Parameters:

-   -   Activity ID Number    -   User contesting the transfer

ReleaseTransfer

Description: Updates the PIC activity record with the status ofreleased. Calls the data access Update Status routine. Boolean procedurereturning true if successful.

Parameters:

-   -   Activity ID Number    -   User releasing the transfer

Data Access Routines for PIC

FindPICbyPIC

Description: Gets a PIC record from PIC Activity based on a date passed.The routine passes along a flag which indicates whether the requestingbank has the right to see the entire PIC information or just a limitedview. Boolean procedure returning true if successful.

Parameters:

-   -   Routing Number of User requesting the find    -   PIC    -   Date

Stored Procedure Called: pfindpic_picid

FindPICbyAction

Description: Get a PIC activity record by the activity ID number

Parameters:

-   -   Activity ID Number

Stored Procedure Called: pviewwpicactivity

FindPICbyComCity

Description: Get a list of PICs by querying on Company name and cityname

Parameters:

-   -   Routing Number of User requesting the find    -   Corporate Name    -   City Name

Stored Procedure Called: pfindpic_name

FindPICbyRTNDDA

Description: Retrieve a PIC by Routing Number/DDA number for a specificdate. The routing passes along a flag which indicates whether therequestor has the right to see the entire PIC information or just alimited view.

Parameters:

-   -   Routing Number of User requesting the find    -   Routing Number of the PIC    -   DDA Number of the PIC    -   Date

ValidateEffectiveDate

Description: Validate if a specific date is a business date: Also mustbe within 90 days.

Parameters:

-   -   Effective Date

Stored Procedure Called: pvalidateRTN

ValidateRTN

Description: Validates whether a routing number belongs to the user'sbank

Parameters:

-   -   Routing Number of requesting User    -   Routing Number to verify

Stored Procedure Called: pvalidateRTN

ValidateRTDDAUnique

Description: Verifies the Routing Number/DDA Number combination does notalready exist for any PIC,

Parameters:

-   -   DDA Number    -   Routing Number

Stored Procedure Called: pvalidatertn_DDA

GetActivitybyCorpName

Description: Gets all PIC activity records for a given corporate name.If dates are supplied, the records are restricted between the dates.Records are also restricted based on the user RTN.

Parameters:

-   -   RTN of the user requesting the search    -   Corporate Name    -   Optional Start date and End date

Stored Procedure Called: pfindUA_Name

GetActivitybyStatus

Description: Gets all PIC activity records with a given activity status.If dates are supplied, the records are restricted between the dates.Records are also restricted based on the user RTN.

Parameters:

-   -   RTN of the user requesting the search    -   Activity Status    -   Optional Start date and End date

Stored Procedure Called: pfindUA_Status

GetActivitybyType

Description: Gets all PIC activity records with a given activity type.If dates are supplied, the records are restricted between the dates.Records are also restricted based on the user RTN.

Parameters:

-   -   RTN of the user requesting the search    -   Activity Type    -   Optional Start date and End date

Stored Procedure Called: pfindUA_Type

GetActivitybyPIC

Description: Gets all PIC activity records for a given PIC., If datesare supplied, the records are restricted between the dates. Records arealso restricted based on the user RTN.

Parameters

-   -   RTN of the user requesting the search    -   PIC ID Number    -   Optional Start date and End date

Stored Procedure Called: pfindUA_PICID

GetActivitybyUserName

Description: Gets all PIC activity records created by a specific user.If dates are supplied, the records are restricted between the dates.Records are also restricted based on the user RTN.

Parameters:

-   -   RTN of the user requesting the search    -   User Name    -   Optional Start date and End date

Stored Procedure Called: pfindUA_User

A functional process model illustrating an approach to gather businessrequirements is depicted in FIG. 7. In developing the process model,potential PIC functionality categories from registration to reportingare defined.

The sections that follow outline the detailed functional requirementsrelated to the PIC to the framework outlined in FIG. 7.

Register Bank Participants

Business customers who use the PIC functionality must have DDAs at abank registered with the trusted third party to distribute PICs. Banksparticipating in the system are the primary channels for reachingbusiness customers for all PIC activities, from marketing tomaintenance. Preferably, no direct interaction between businesscustomers and the system support team is expected. One of the advantagesof the implementation of the PIC is to provide services to banks thattransparently enhance bank relationships with their customers.

Create Bank Profile

To establish a PIC system relationship with a trusted third party,individual banks preferably complete a formal registration process.Formal registration requires each bank to provide entity-typeinformation about itself. The trusted third party uses this informationto create a bank profile, which is stored as part of the systemdatabase. Bank profiles serve as the foundation for providing customerservice for the complement of system enhancements. The informationstored in the bank profile includes: bank name, primary address, primarycontact, EPN registered, CHIPS registered, etc.

In addition, the profile includes information related to individual bankpreferences. Examples of preference information include requirementsrelated to maintenance approval and preferred data format(s).Furthermore, if a bank uses service providers to maintain individualDDAs, then a list of approved service providers authorized to access andmaintain PIC data on a member bank's behalf is stored in the bankprofile. The bank profile is flexible and capable of accommodatingadditional data elements.

Validate Bank Profile

Individual bank profile information is collected and validated prior toissuing PIC numbers to customer DDAs. After profile information isreceived, the system performs a validation process, checking allelements of the bank profile for accuracy.

Initially, all banks registering for the system are to be currentparticipants of CHIPS or EPN. After initial deployment, banks are ableto register for services without being CHIPS or EPN participants.However, such banks, who would typically be correspondents of CHIPS orEPN participants, must complete a bank profile with the system to gainaccess to PIC administrative functions. Also, non-participant banks mustspecify how transactions are to be executed, either throughcorrespondent relationships or the Federal Reserve. Existing CHIPS orEPN system participants are not required to execute additionalagreements for PIC. For current participants, the trusted third partyexpedites the registration process by leveraging information from theEPN and/or CHIPS platforms to automatically complete individual bankprofiles. In this situation, the registering bank is required to supplyany missing profile information and confirm the auto-populated profiledata elements.

Build Initial PIC User Base

Once bank registration is complete, a bank is eligible to begin theprocess of requesting PICs for existing DDAs. To promote extensiveparticipation and to accelerate PIC adoption, the system wouldpreferably mass enroll all appropriate participating bank businesscustomer DDAs in the PIC program. Mass enrollment, or mass PIC issuance,preferably takes place via bulk file transfer. Bulk file transfer isdescribed later.

Perform Mass Enrollment

Participating bank business customers are automatically assigned a PICfor each of their DDAs via a mass enrollment process. The massenrollment process relies on customer DDA data supplied by participatingbanks to populate the PIC database. Data is supplied by participatingbanks via a database extract file. The specifications for the databaseextract file are standard and defined by the system. Data fieldsrequired to complete DDA mass enrollment are identical to data fieldsrequired to complete a single DDA PIC enrollment. The database extractfile elements preferably include: DDA name, address, account type,routing number, account number, etc.

Only information required for PIC creation is included in the massenrollment requirements. Sensitive information (e.g., credit scoring) isnot a PIC requirement.

Participant banks would preferably request PIC numbers only for DDAsthat receive remittance payments. As a result, banks should identify andexclude non-remittance accounts from the mass enrollment file. Thesystem preferably accepts files via ConnectDirect (only for banks whocurrently have software installed and frame-relay links to the trustedthird party), in cases where banks do not have connectivity viaSWIFTNet. Files may also be accepted via the Internet. In order to makethe mass enrollment process simple, the system does not require changesto current bank DDA systems. Upon completion of the mass PIC enrollmentprocess, the system returns a file containing all PIC numbers and theirrespective DDA information to participating banks. The PIC file isreturned to banks in the same data format in which it was received. Whenformat or data omission errors occur in the mass enrollment file, theindividual items in error are returned to the participating bank with areject code. The entire enrollment file is not rejected unlesssignificant format problems exist.

Issue PICs

Request FIC

PIC numbers are issued for business customer accounts by the system uponrequest from a registered bank or an approved service provider. Bankswho are not system registered cannot request PICs. Also, a bank (orapproved service provider) can request PICs for their business customeraccounts only. While business customers actually own PICs, therequesting bank (or approved service provider) is responsible for thePIC until the PIC is closed or transferred to another bank. PICrequesting banks are required to provide the information necessary forPIC creation. PIC responsible banks also coordinate all PIC maintenancefor related customer and correspondent bank accounts. Participatingbanks can request PIC numbers through multiple channels. These channelsinclude: Batch file request; real-time request via web-site; andreal-time request via messaging.

Individual PIC creation requests are initiated via a system website ormessaging over SWIFTNet. Such transactions may also be executed via theInternet.

Assign PIC

Upon receipt of a PIC assignment request, the system checks therequesting DDA number to determine if it has been previously issued aPIC. If a PIC already exists for a given DDA number, the assignmentrequest is rejected. Otherwise, the system creates a new record andassigns a PIC. The system issues a single PIC for each DDA number. A PICis the same for a DDA whether transactions occur through EPN or CHIPS.Unlike PIC numbers, system routing transit numbers will differ for theCHIPS and EPN platforms, or any other platforms that may be supportedfor PICs. However, the system allows multiple PIC numbers to point to asingle DDA to accommodate cases where companies merge or bankarchitecture changes.

PIC numbers are assigned randomly from a given block of numbersdetermined by system administrators. PIC numbers range from a minimum ofeight to a maximum of 17 numeric characters. Initially, eight digitnumbers are assigned—six digits plus two check digits. The tworight-most digits comprise the two check digits. The six left-mostdigits in an eight-digit PIC are used to compute the check digits.

The two check digits are employed to mitigate transposition errors andensure that each PIC numbers are unique. Insertion of leading zeroes isnot required to use PIC numbers.

Provide PIC Information

After assignment of a PIC to a DDA number, the PIC database record ispopulated with data provided by the requesting bank. The data elementsfor a PIC record include: company name, company address, bank name,routing number, account number, account type, status, etc.

Account type, as defined by the system indicates whether the account isa business account, internal account, for correspondent relationships,or a consumer account for use in a home banking context. The PICdatabase record also indicates the EPN/CHIPS enabled status of anaccount if applicable. This status is important as some banks oraccounts may not be registered with both EPN and CHIPS. The status fieldreads as enabled, disabled or suspended. If a bank is both EPN and CHIPSregistered, PIC numbers are enabled for both payment systems at the timeof PIC assignment. In addition to system specific status, the PICdatabase also contains information related to the overall status of thePIC. This status can be active, suspended or closed. Upon assignment ofa PIC, the overall status defaults to active.

Many banks rely on correspondent relationships to execute CHIPSpayments. There can be multiple bank process links associated with asingle CHIPS payment. These links create a CHIPS “payment chain.” As aconsequence, the PIC database record, for a CHIPS enabled customer whosebank is not a direct CHIPS participant, requires an additional dataelement. This element contains the PIC associated with the account atthe CHIPS participating bank. By capturing the PIC of the next bankaccount in the chain, iC&S allows for easy maintenance of correspondentrelationship information. A correspondent relationship change requires achange to a single PIC in the payment chain.

Process Payments Originate Payments

The use of PICs by buyers and sellers requires minimal changes, if any,to originating bank's and receiving bank's systems. The system routingnumber and PIC are used in the same manner as routing numbers andaccount numbers are used currently in, for example, EPN. PIC numbers areleft justified with any leading zeros being insignificant. EPN and CHIPSrecognize PIC transactions through a PIC-specific routing numbercontained within the payment instruction. For EPN, the flag is a ninedigit system routing number. This is a unique number identifying aparticular financial institution and which is assigned by, andregistered with, an independent organization, preferably with ThompsonFinancial. For CHIPS, the flag is a four-digit number determined by theClearing House. Once a transaction is identified as an a system PICtransaction, the EPN/CHIPS platform scans the account number field inthe payment instruction and reads the PIC to retrieve the associatedaccount information. For all system transactions, the account number/PICfield is mandatory.

Receive Payment Instructions

Processing a PIC payment refers to the process of receiving a paymentinstruction, identifying the instruction as a PIC transaction,validating the PIC, translating the PIC and forwarding the payment tothe beneficiary's bank. The PIC payment process of the present inventionmay be integrated with the processes of EPN and CHIPS. While it may bepreferable initially to use the system to facilitate credit originationonly, blocking all debit originations, it is possible, and may beadvantageous, to use PIC for certain types of EPN debit transactions.PIC credit payments require the receiving customer to have a PIC. Thepayment originator is not required to have a PIC.

When an originating bank is not an EPN participant, ACH payments arerouted to the Federal Reserve. The Federal Reserve recognizes PICtransactions from the system routing number and credits asystem-specific settlement account. EPN then performs the PICtranslation, payment delivery and settlement to complete thetransaction. A similar process is used for processing CHIPS transactionsin cases where an originating bank is not a CHIPS participant and sendswire transactions (with PICs) though the Federal Reserve for processing.

To execute CHIPS payments, participating banks must process paymentsthrough a CHIPS registered participant. All CHIPS registeredparticipants and their correspondent banks are required to have PICs.Finally, implementation of the PIC concept does not adversely impactoverall EPN/CHIPS platform performance.

Validate PIC

PIC numbers are validated before account information look-up can occurand before the payment can be sent to the receiver. The EPN and CHIPSplatforms each have a copy of the PIC database in order to validate andtranslate PICs. These PIC databases reside on the EPN and CHIPSplatforms and are updated daily by the master PIC database (immediatelyafter previous day changes have been recorded). When validating the PICagainst the PIC database, the payment systems return (EPN) or reject(CHIPS) the payment for the following reasons: PIC is invalid; and PICstatus is not active.

EPN and CHIPS capture the return/rejection error reason, which isaccessible by internal customer service. If a PIC is rejected in CHIPS,it is rejected with the generic “invalid” response currently used by thesystem.

Translate PIC

Once a PIC is validated, EPN/CHIPS translates the system routing numberand PIC to the bank routing number and customer DDA number usinginformation contained in the PIC database. Because of the direct linkagebetween PIC and EPN/CHIPS, PIC translation is available during allEPN/CHIPS processing windows. For CHIPS PIC transactions, where a chainof banks is involved, CHIPS retrieves and translates the PIC of allbanks in the payment chain and places the information in the paymentrecord. The system may truncate certain fields. The PIC numbers areincluded in the outbound transaction.

Handle Rejected/Returned Instructions

ACH reversals are allowed for PIC transactions. For EPN returns fromreceiving banks, EPN identifies which returns are PIC transactions andrequire reverse translation. EPN then translates the bank routing numberand DDA number back to the system routing number and PIC prior toreturning a transaction to an originating bank. Furthermore, the systempasses all returns to originating banks with the same information and inthe same format that the original instruction was received. However, asystem tag is added to identify returns. A generic reason code (i.e.,invalid account) and addenda records are also included in all returnedtransactions.

FIGS. 2 through 4 provide a summary description of the paymentprocesses.

Provide Customer Service

The system provides customer service to banks through the current EPNand CHIPS customer service organization(s). Preferably, the systemprovides service directly to banks, and their correspondents while theresponsibility to communicate directly with business customers resideswith banks.

Provide Service Channels

PIC customer service is provided to banks via multiple channels toaccommodate individual bank preferences/processes. PIC service isavailable 24 hours per day, seven days a week via a combination of thefollowing service channels and mediums: Self-service web-site; Bulk-filetransfer; Messaging; Email; and Telephone.

The service website is accessible via the SWIFTNet private network. Inthe future, banks may access the website via the Internet. The systemwebsite includes functionality related to frequently asked questions,on-line help and contacts. Customer service email addresses andtelephone numbers are listed on the web site.

Look-Up PIC

A PIC look/up search capability is provided to banks via multiplecustomer service channels. The PIC lookup provides a method for bank (orapproved service provider) users to view the PIC database to retrievetheir PICs and related information. The PIC lookup function issearchable on the following fields in the PIC data record: PIC, DDAnumber, account name and address. A public PIC directory enables buyersto find seller PIC numbers. Bank customers are able to opt-in to thepublic PIC directory.

Maintain PIC

Maintaining accurate account information is critical to achieving a highincidence of PIC transactions. For this reason, the system philosophyrelated to PIC service places responsibility for PIC databasemaintenance with participating banks. Only authorized system customerservice, participating bank or approved service provider personnel canaccess the PIC database to perform maintenance functions. When viewingor maintaining the PIC database, users are only granted access to PICSthat relate to accounts of their bank customers. Basic PIC maintenancefunctions include: Close PIC; Change PIC Database Information; TransferPIC; and Administer Profiles.

Close PIC. When a business customer closes a PIC through its bank, thePIC is retired forever. While PIC closings are infrequent, they mayoccur in cases of account closings due to bankruptcy or merger.

Change PIC Database Information. Changes to PIC database information arefile transfer-based, message-based, web-based or telephone-based. Withregard to file transfers, the system accepts PIC maintenance requestfiles several times a day, in both XML and flat file formats. XML is thepreferred file format. Files follow a format determined by the systemand must be authorized prior to transfer.

All information contained in the PIC database record (except for thePIC) can be changed through maintenance requests. However, requests madethrough the website or through messaging are restricted to changes ofnon-transaction critical information. Information considered transactioncritical is any information required to process a payment transactionincluding routing and DDA numbers.

All maintenance requests include an effective date field. Once a requestis received by the system the changes are not applied until theeffective date specified. If no effective date is identified, thechanges appear immediately and are placed in production systems thefollowing day. Furthermore, the system provides banks with the option torequire approval for all web or message-based maintenance requests ofcritical information.

Only a single change request and a single transfer request can bepending for a given PIC at any time. The system processes both if thetransfer effective date is after the change effective date. Otherwise,the change request is ignored at the time of transfer. If a user needsto make additional changes after submitting a maintenance request, theymust cancel the original request and include all changes in a newrequest. Bank users have the ability to access all outstanding andpreviously applied updates to its. PICs.

Also, when web or message-based maintenance requests are submitted,initiators of the request receive an automated confirmation screen ormessage that contains relevant transaction advice.

Finally, participating banks have a copy of the PIC database for theirDDA accounts to facilitate look-up and assist in identification of on-ustransactions. To update the bank's customer PIC database copy, a bankrequests an update file. This request includes a specific date range todetermine the update requirements. If no date range is provided, thesystem default is to provide all updates since the date of therequesting bank's last recorded update request. Updated PIC files arereturned to banks in the same format in which they were received. Asnecessary, the system provides banks with a complete file of all PICdata belonging to their customers.

Transfer PIC. The transfer process allows a PIC to remain with abusiness customer regardless of changes in the business customer's bankrelationship. To complete a PIC transfer between banks, the receivingbank, or its approved service provider, must initiate the transfer.Initiation of a transfer requires proper authorization from the businesscustomer associated with the transferring PIC. The receiving bank mustalso provide the system with the transferring bank and the new bankaccount information for validation purposes. Once a transfer isrequested, it generates a notification to the bank surrenderingresponsibility for the PIC.

Administer Profiles. As part of the system, direct or indirectparticipants of the EPN and CHIPS systems must establish bank entityprofiles and individual user profiles. The self-serve website has anadministrator restricted section that provides functionality toadminister both types of profiles. The system requires four superadministrators (two for EPN and two for CHIPS) from each participatingbank. Super administrators are responsible for managing their bank'suser profile information. Critical data elements in the bank profile arerestricted, including settlement, routing, translation and billinginformation. Changes to critical information occur through off-lineprocesses. The functions to administer user profiles include changingaccess controls, resetting password, creating user profiles anddisplaying bank user profiles records. Administrative updates occur inreal-time.

Provide Technical and Bank Support

The system provides bank support via the current EPN and CHIPS customerservice organization. System administrators and customer servicerepresentatives have user profiles to control access and restrictfunctionality and administrative rights. Customer service is able toperform all maintenance functions on behalf of banks and respond to bothphone and email inquiries.

Manage Risk and Control. System

To ensure proper security of PIC data and to protect againstunauthorized changes of information, the system has a methodology forsystem control and risk management. There are four key areas of thismethodology:

-   -   Manage technical architecture    -   Authenticate and control user access    -   Track PIC database activity    -   Secure information

Technical architecture is outside the scope of the business requirementseffort and is not outlined in this document.

Authenticate and Control User Access

Participating banks are responsible for designating four superadministrators, two for the EPN platform and two for the CHIPS platform.Super administrators are responsible for PIC account maintenance. Eachsuper administrator can delegate responsibility for PIC maintenance andadministration as they see fit; however, only authenticated users arepermitted to make changes to the system database. An authenticated usermust have a system user-profile. This profile contains several dataelements including: user name, password, title, bank name, contactinformation, etc. There is also an employee type data element thatidentifies whether a user is bank or a system employee. User profilesare used to authorize a user's access, maintenance and administrativerights via all channels of communication.

Access to the system website is restricted by a login that requires auser to enter a username and password. User names and passwords must beat least six characters long, be a combination of alpha and numbercharacters, and changed on a periodic basis. The user profile contains astatus field that indicates if the profile is active, disabled orclosed. A disabled status occurs when a profile has not been accessedfor one month or after three failed login attempts. Once a profile isdisabled, the user is restricted from logging onto the website until anadministrator resets the user profile status to active. Changes relatedto all non-transaction critical PIC data such as name and address areallowed via the website. However, changes to transaction criticalinformation (e.g., routing and account number) are handled off-line.This limitation allows the Clearing House to more closely monitorchanges that affect PIC transaction processing.

Track PIC Database Activity

To manage risk, all modifications to the PIC database are tracked andlogged. Changes to he PIC database, such as PIC assignment, maintenanceand transfer are captured in a PIC activity log including the “beforeand after” information related to modified fields, the name of the userwho performed the modification, and the date and time the changeoccurred. The activity log is accessible to bank super administratorsvia the website. All other payment related activity is tracked on thecurrent EPN/CHIPS platform and is not stored in the PIC database.

Secure Information

Bank customer DDA information is confidential and cannot be used foranything other than PIC services initiated by participating banks onbehalf of their customers. Sensitive data on the PIC master andEPN/CHIPS databases is encrypted. At a minimum, routing numbers, DDAnumbers and taxpayer identification numbers must be encrypted. Tobolster security, the system preferably uses of SWIFTNet to receive andtransmit customer enrollment, update and information files between thesystem and participating banks. For SWIFTNet and ConnectDirecttransmissions, the system relies on security inherent to the network andsoftware, as well as smart cards/digital certificates to receive andtransmit customer enrollment, update, and information files.Furthermore, SWIFTNet has closed user groups that restrict unknownentities from accessing the network. In the future, the Internet may beused for transmission. In this instance, the system requires a minimumof 128-bit or Triple Des encryption.

Bill Participants

Standard pricing for PIC transactions is established. PIC relatedtransaction fees are tracked in the current EPN/CHIPS platform and donot require a separate billing advice. Rather, EPN/CHIPS bills includethe number of PIC transactions performed during the billing period andrelated charges. Banks make appropriate payment to the Clearing Housefor PIC services electronically.

Provide Reports

Because the PIC feature is an enhancement to the existing Clearing Housepayment systems, there are no additional reporting requirements relatedto the PIC feature. All payments related and statistical reports areprovided through existing EPN and CHIPS reporting capabilities.

Reporting requirements related to the PIC database and maintenancefunctions are handled through bulk file transfer and the self-servewebsite. Banks can receive a file that includes all customer PICs.Reporting requirements for maintenance functionality includepending/completed PIC maintenance requests and listings of user profileusernames and passwords. This information is accessible via the iC&Swebsite.

Several processes with respect to the system are described below withreference to FIGS. 8 through 33. Interaction with the PIC system isaccomplished through various screens. The following describes some ofthe PIC screen definitions. These screen definitions may be developed toshow various processes performed using the PIC database.

PIC Screen Definitions: Welcome Screen

Initial screen presented at IC&S web site. Contains text describing iC&Sand anything else a business group wants. The Welcome Screen alsocontains a Login Button, user and password fields and skip Login ScreenButton.

Login Screen

Contains entry fields for Usercode and Password. Successful login bringsyou to Menu screen. After a User logs in we know which bank the userbelongs to and his/her access rights.

Menu Screen

Contains initial access to all capabilities that is defined for theuser. Those things not allowed for the user are not visible oraccessible. Those users that have Update capability will also haveInquiry capability by default. Possible Options are

PIC Inquiry Update PIC Activity Inquiry Update (approve/cancel) MemberInquiry Update Member Activity Inquiry User Inquiry Update User ActivityInquiry

PIC Inquiry Inquiry by PIC

This inquiry will display the PIC Detailed. Screen. The PIC does nothave to belong to the controlling bank. Do we show all accountinformation? If inquiry is done to re-route payments the accountinformation will be needed.

Inquiry by Account number

This inquiry is restricted to the PICS owned by the banks. Returned isthe PIC List Screen. If there is a list then the user could select anentry for the detailed information.

Inquiry by Name

This inquiry is restricted to the PICS owned by the banks. Returned isthe PIC List Screen. If there is a list then the user could select anentry for the detailed information. The inquiry should be able to berefined by city and/or state.

PIC List Screen

This screen will list possible candidates found from an inquiry. It willdisplay PIC, RT number and Name and Address info, (as much as possible).

PIC Detail Screen

This screen will show detailed information regarding a specific PIC. Ifthe user is from not from the controlling bank customer contactinformation is not displayed. If the user is not allowed to see accountinformation the account number is not displayed.

PIC Activity Inquiry.

This permits inquiry by “closed/open” activity, and includes the optionof looking at all closed activity. A qualifier by date range and/or PICnumber or account number is used. This functionality Also allow inquiryby RT number. The results of the inquiry returns the Activity Listscreen.

PIC Activity List

This screen list activity records based on the Activity Inquiry Screen.It will summarize the status, action, for an PIC activity. Selecting anactivity record will display the PIC Activity Detail screen.

PIC Activity Detail

This screen will contain all of the detail information regarding theactivity record. If the activity record is open and the USER has updatecapabilities the activity record may be approved or cancelled. If thebank reviewing has 2-step approval process the activity goes in asproposed and must be approved by someone with PIC update capabilities.If the bank has dual operator approval option then the approval operatormust be different from the entering operator.

Member Inquiry

This screen allows an authorized user to view MEMBER profileinformation. This screen will display bank names, account, wire chainingand other configuration information. If a bank list exits it isdisplayed and if categories are defined for the bank they are alsodisplayed.

Member Update

This screen allows changes to the MEMBER profile by an authorized user.An add will be performed by IC&S staff after signup information isgathered. Changes are made by the Member. A delete may only be performedby IC&S staff. When a change is made the member profile is immediatelyupdated and a closed member activity record is automatically created.

Member Activity Inquiry

This screen is used to display the Member Activity List screen by anauthorized user. The activity may be selected by date range.

Member Activity List

This screen is used to display a list of member activity update records.It will display a summary of activity and dates. Selecting an activityrecord will display the Member Activity Detail screen.

Member Activity Detail Screen

This screen is used to display the Member profile change detailinformation.

USER Inquiry

This screen allows an authorized user to view USER profile information.This screen will display all access capabilities of a USER.

USER Update

This screen allows changes to the USER profile by an authorized user.When a change is made the USER profile is immediately updated and aclosed USER activity record is automatically created.

USER Activity Inquiry

This screen is used to display the USER Activity List screen. Theactivity may be selected by date range.

USER Activity List

This screen is used to display a list of USER activity update records.It will display a summary of activity and dates. Selecting an activityrecord will display the USER Activity Detail screen.

USER Activity Detail Screen

This screen is used to display the USER profile change detailinformation.

User Options Matrix

PIC Inquiry Update Account Information PIC Activity Inquiry UpdateMember Inquiry Update Member Account Inquiry (If Member Update thenInquiry) USER Inquiry Update USER Account Inquiry (If USER Update thenInquiry)

PIC Maintenance

The maintenance of PIC fall within 4 categories, Add, Change,Delete(close), and Transfer.

PIC ADD: This screen is used to create a new PIC. Some of the fields arerequired while others are optional. Required fields are the RT numberand DDA number that represent the account, Name and Address of thecustomer and the CHIPS/EPN enabled flag. Optional fields are the Contactinformation. If CHIPS enabled an optional “wire” name and address may beentered. If the “wire” name and address is not specified the customername and address will be truncated to fit into this name and address.

PIC CHANGE: This screen is used to change and existing PIC. It willcontain all the fields that an ADD screen contains. Any field may bechanged except the RT number field. This may be changed only with a PICTransfer screen.

PIC TRANSFER: This screen is used to move a PIC from one bank to anotherbank. The new bank must enter the new RT and DDA number for the account,and also provide the old RT and DDA number. Any of the other fields mayalso be changed at this time. The “old” bank will be notified of thetransfer and have 48 hours to contest the transfer. All transfer will beeffective 2 days after approval.

PIC DELETE: PICS are never actually deleted, but are considered to beclosed. They can be reopened at a later date.

System Processes

FIGS. 8 and 9 together show a Create a Bank Profile process. Thisprocess is accomplished mostly offline by internal users at a depositoryinstitution. In FIG. 8, at step S1000, the user is presented with theirhome page. At step S1002, the user clicks on an icon for Create a BankProfile. The user is then presented, at step S1004 with a blank bankprofile page. At step S1006, the user enters data and at step S1008 hitssubmit. At step S1010, if the bank is in the system, the flow proceedsto step S1012, at which point the user is presented with an error pagesaying that the bank has already been added. If the bank is not in thesystem, then at step S1014, it is determined if the information has beenentered correctly. If so, the flow proceeds to section A2 of FIG. 9.

At FIG. 9, at step S1016, the user is presented with a screen that hasthe information they typed in and the user is asked to either create abank profile or change entered data. At step S1018 it is determinedwhether the create bank profile or the don't create bank profile hasbeen pressed. If the create a bank profile button is pressed at stepS1020, then flow proceeds to step S1024 at which the user is presentedwith a success screen that the profile has been created and the processterminates. If the don't create a profile button is pressed at stepS1022, then flow proceeds to step S1026 at which the user is presentedwith the request cancelled screen and the process terminates.

FIG. 10 is a flowchart of a Delete a Bank Profile process, accomplishedby users with proper authority and access at the trusted third party. Atstep S2000, the user is presented with their home page. At step S2002,the user clicks on delete a bank profile. At step S2004, the user ispresented with a page offering the choice of entering a bank name orselecting from a listed bank name. If the user clicks on a bank name, atstep S2005, the flow proceeds to section A3 of the figure. If the usertypes in a bank name at step S2006 and clicks on submit at step S2007,then at step S2008 if the bank exists on the system, the flow proceedsto section A3. Otherwise, flow returns, with an error message, to stepS2004, and the user is again asked to enter a bank name or select a bankname.

At step S2010 the user is presented with a bank profile for the selectedbank. Then, to delete the bank profile, at step S2012 the user clicks ondelete. At step S2014 the user is presented with a screen asking if theyare sure they want to delete the profile. If at step S2016 the userclicks at step S2017 on delete, then at step S2018, the user ispresented with a Success screen and the flow terminates. On the otherhand, if the user at step S2019 clicks on Do Not Delete, then at stepS2020, the user is presented with a Request Cancel screen and the flowterminates.

FIG. 11 shows the flow for a Modifying a Bank Profile process. This is apermission based process, whereby only those users with properpermission may perform this process. At step S2100, the user ispresented with their homepage. At step S2102, the user clicks on Modifya Bank profile. If it is determined at step S2104, that the user is nota trusted third party (TTP) user, then at step S2106, the user ispresented with an editable version of the bank profile. At step S2108,the user enters changes, then at step S2110, the user clicks on submit.If it is determined at step S2112 that the required fields are completedcorrectly, then the flow goes to section A4. If it is determined at stepS2104, that the user is a trusted third party (TTP) user, then at stepS2114, the user is presented with a page and asked to enter a bank nameor click on a name. If at step S2114 the user sees the bank name, thenat step S2116, the user clicks on the bank name and flow proceeds tosection B4. If the user is not provided a bank name to click, then atstep S2118, the user types in a bank name. At step S2120, the userclicks on submit, then at step S2122, the user is asked whether theirbank exists in the system. If yes, flow proceeds to section B4. If no,flow proceeds back to S2114 with an error message added to what ispresented to the user. At step S2124, the user is presented with ascreen that has the modification of the bank profile and asked if theywant to modify or cancel the modification request. At step S2126, theuser must decide to either modify or not to modify. If the user decidesto modify at step S2126, then at step S2128, the user clicks on modify,and at step S2130, the user is presented with a success screen and theflow ends. If the user decides not to modify at step 2126, then at stepS2132, the user clicks on do not modify. At step S2134, the user ispresented with a cancel request screen stating that the user was notmodified and the flow ends.

FIG. 12 shows the flow for a Change a Route process. This process isaccomplished by the trusted third part. At step S2200, the user ispresented with their homepage. At step S2202, the user clicks on changea route. At step S2204, the user is presented with a page to enter the 9digit bank number or bank name. At step S2206, the user is presentedwith a page and asked for a route number and an effective date. At stepS2207, the user clicks on View Routes. At step S2208, the user ispresented the route table for that bank and the flow proceeds to sectionA5. At step S2209, the user enters data and the flow proceeds to sectionA5. At step S2210, the user must choose: Add Route, Move Route, DeleteRoute, View Route Table. At step S2212, the user has clicked on AddRoute, and the flow proceeds to step S2214, to determine whether Routeexists. If no, flow proceeds to section B5. If no yes, flow proceeds tostep S2216, where it is determined if required fields has been completedcorrectly? If no, flow proceeds, with an error message, to section B5.If yes, then at step S2218, the user is presented with a screen thatasks if they are sure they want to do that activity. At step S2220, theuser must decide to do activity or cancel request for activity. At stepS2222, the user has clicked on “do activity.” Then at step S2224, theuser is presented with a Success screen and the flow terminates. At stepS2226, the user has clicked on “cancel request for activity.” Then atstep S2228, the user is presented with a Success screen stating therequest was canceled and the flow terminates. At step S2230, the userhas clicked on Delete Route, then at step S2232, it is determined ifRoute exists. If yes, flow proceeds to step S2216. If no, flow proceedsto section B5. At step S2234, the user clicks on Move Route which is aplaceholder. At S2236, the user clicks on View Route Table, and the flowproceeds to section B5.1.

FIG. 13 is a flowchart of the View PIC Activity log process. In thisprocess, all user related activities should appear based upon a searchcriteria. At step S2400, the user is presented with their homepage. Atstep. S2402, the user clicks on the View PIC Activity Link. At stepS2404, it is determined if the user has access to multiple banks. Ifyes, then at step S2406, the user is presented with page to enter searchcriteria for activity and a list of the most recent activities for allbanks they have access to. At step S2408, the user is presented with achoice to enter search data or click on an activity. At step S2410, userthat has entered search criteria clicks on the Submit Button. If anactivity is selected, the flow proceeds to section C6. If at step S2404the answer is no, then at step S2411, the user is presented with page toenter search criteria for activity and a list of the most recentactivities for all PICs which he has access to and then the flowproceeds to step S2408. At step S2412, it is determined if the userrequested find selected criteria? If no, then flow proceeds to sectionA6 with an error message. If yes, then flow proceeds to step S2414,where it is determined if the user has access to this information. Ifno, then flow proceeds to section A6, with an error message. If yes,then flow proceeds to step S2416, the user is presented with searchresults, 20 per page. At step S2418, the user clicks on the PIC activityto View, and at step S2419, the user is presented with page of activityinformation and the process terminates. Alternatively, at step S2420,the user clicks to search again, and the flow proceeds to section A6.

FIG. 14 is a flowchart of the View Bank Profile Activity log process. Atstep S2500, the user is presented with their homepage. At step S2502,the user clicks on the View Bank Profile Activity Log Link. At stepS2504, it is determined if the user has access to multiple banks. Ifyes, then at step S2506, the user is presented with Bank Profileactivity for the multiple banks they have access to. If the activity isin the future and the user has right to perform that activity, a CANCELbutton preferably appears to allow for the cancellation of that pendingactivity. At step S2508, it is determined if the user found what theywanted on log. If yes, then the process terminates. If no, then the flowproceeds to step S2510, where the user enters Search Criteria. At stepS2512, the user clicks on Find an Activity and the flow proceeds tosection A7. If at step S2504, the answer is no, then at step S2514, theuser is presented with the Bank profile activity log after which theflow proceeds to step S2514.

FIGS. 15A and 15B are a flowchart of the Create a User process. At stepS2600, the user is presented with their homepage. At step S2602, theuser clicks on the Add A User Link. At step S2604, it is determined ifthe user has access to create the users at Multiple banks. If yes, thenat step S2606, the user is presented with a list of banks they haveaccess to add the users to. At step S2608, the user hits a bank name. Atstep S2610, the user gets page with the types of the users they areallowed to create. If at step S2604 the answer is no, then flow proceedsdirectly to step S2610. At step S2612, the user clicks on a the usertype. At step S2614, the user is presented with an a user profile setupscreen. At step S2616, the user enters requested information. At stepS2618, the user hits submit. At step S2620, it is determined if therequired fields were completed correctly. If yes, flow proceeds tosection A8. If no, flow proceeds to step S2614 with an error message. Atstep S2622, the user is presented with a screen that has the informationthey typed in on it and asked to either Create User or Change Data. Atstep S2624, the user has a decision whether to hit Create User, Don'tCreate User, or hit Back Button in browser. If at step S2625 the userhits Create User, then at step S2626, the user is presented with aSuccess screen that the user has been created and the processterminates. If instead the user, at step S2627 hits Don't Create User,then flow proceeds to step S2628, and the user is presented with RequestCancelled screen and process terminates. If the user, at step S2629 hitsthe Back Button in the browser Window, then at step S2630, the user maychange data and the flow proceeds to section D8.

FIGS. 16A and 16B are a flowchart of the Delete a User process. Notethat a user cannot delete themselves. At step S2700, the user ispresented with their homepage. At step S2702, the user clicks on theDelete User Link. At step S2704, it is determined if the user has accessto delete the users from Multiple banks. If yes, then at step S2706, theuser is presented with a list of banks they have access to delete theusers from. At step S2708, the user hits a bank name. At step S2710, theuser is presented with a page with the names of the users they haveaccess to delete. There are check boxes next to each name. If at stepS2704 the determination is no, then the flow proceeds directly from stepS2704 to step S2710. At step S2712, the user can either click name orenter a name or UserID in a provided form field to search for that user.If at step S2714, the user clicks on the Check box next to the user'sname, then at step S2715, the user hits Delete and the flow goes tosection A9. If instead, at step S2716, the user enters name or UserID inform field, then at step S2717, the user hits search for user, and atstep S2718, the user is presented with a page with a user or users thatmatch that search and the flow proceeds to section B9. At step S2720,the user is asked whether they are sure they want to delete user. Atstep S2722, the user decides whether to Delete Profile or Don't DeleteProfile. If the user at step S2724, hits Delete, then at step S2725, theuser account is marked for deletion in the system database and at stepS2726, the user is presented with a Success screen that user has beendeleted, and the process terminates. If instead, at step S2727, the userselects Don't Delete Profile, then at step S2728, the user is presentedwith a screen stating their Request to delete has been cancelled and theprocess terminates.

FIGS. 17A and 17B are a flowchart of a Modify a User process. At stepS2800, the user is presented with their homepage. This is a permissionbased process, whereby only those users with proper permission mayperform this process. At step S2802, the use clicks on the Modify User.At step S2804, it is determined if the user has access to modify usersfrom multiple banks. If yes, then at step S2806, the user is presentedwith a list of banks they have access to modify users from. At stepS2808, the user hits a bank name. Then at step S2810 the user ispresented with a page with the names of users they have access tomodify. If at step S2804 the answer is no, the flow proceeds directlyfrom step S2804 to step S2810. At step S2812, the user can either clicka name or enter a name in a provided form field to search for that user.If, at step S2813, the user clicks a name, then flow proceeds to sectionA10. If instead, at step S2814, the users enters a UserID in the formfield, then at step S2815, the user hits search for user, and at stepS2816, the user is presented with a page with a user or users that matchthat search and the flow proceeds to section B10. At step S2818, theuser is presented with an editable version of that person's profile. Atstep S2820, the user modifies data. At step S2822, the user hits Modify.At step S2824, it is determined if the data was entered correctly. If,no, flow goes back to step S2818 with an error message. If yes, then atstep S2826, the users are asked are they sure they want to modify a useror users. At step S2828, the user decides whether to hit Modify or Don'tModify User. If, at step S2829, the user hits Modify, then at stepS2830, the user account marked modified in the PIC database, and at stepS2831, the user is presented with a Success screen that user has beenmodified and process terminates. If instead, at step S2832, the userhits Don't Modify, then at step S2833, the user is presented with arequest Cancel screen and the process terminates.

FIG. 18 is a flowchart of a View a User Profile process. At step S2900,the user is presented with their homepage. This is a permission basedprocess, whereby only those users with proper permission may performthis process. At step S2902, the user clicks on View User Profile. Atstep S2904, it is determined if the user can View bank users frommultiple banks. If yes, then at step S2906, the user is presented withthe list of banks they have access to view user profiles at or cansearch for bank, and at step S2908, the user clicks on Bank Name. Atstep S2910, the user is presented with a page with the names of usersthey have access to view a profile for. If the user can only view theirown profile, the process skips to section C11. If the determination atstep S2904 is no, the flow proceeds directly to step S2910. At stepS2912, the user can either click on a name or enter a name or ID in aprovided form field to search for that user. If, at step S2913, the userClicks On Name, then at step S2914, the user is presented with the UserProfile and the process terminates. If instead, at step S2915, the userenters name in the form field, then at step S2916, the user hits searchfor user, and at step S2917, the user is presented with a page with auser or users that match that search and the flow proceeds to sectionB11. If, at step S2918, the user enters User ID in the form field, thenat step S2919, the user hits search for user, and at step S2920, theuser is presented with the User Profile and the process terminates.

FIG. 19 is a flowchart of a Log On to The PIC System process. This is apermission based process, whereby only those users with properpermission may perform this process. At step S3000, the user Logs on toSWIFTNet. At step S3002, the user is presented with a browser screenprompting for their userid and password. At step S3004, the user entersData. At step S3006, the user clicks on Submit to submit the data. Atstep S3008, it is determined if the user is authenticated andauthorized. If no, flow returns to step S3002 with an error message. Ifyes, at step S3010, it is determined if the required fields have beencompleted correctly. If no, flow returns to step S3002 with an errormessage. If yes, then at step S3012, the user is presented with theirhomepage and the process terminates.

FIG. 20 is a flowchart of a Change a Password process. First time newusers accessing the system are requested to change the password. Also,request to change password is automatic on password expiration. At stepS3100, the user is presented with their homepage. At step S3102, theuser clicks on a User Change Password link. At step S3104, the user ispresented with a page to enter their old password and new Password,preferably two times. At step S3106, the user clicks Change Password. Atstep S3108, it is determined if the password has been changed. If yes,at step S3110, the user is presented with a Success screen and theprocess terminates. If no, an error message is presented and the processterminates.

FIG. 21 is a flowchart of a Reset User process. At step S3200, the useris presented with their homepage. At step S3204, the user clicks on UserReset User Link. At step S3206, the user is presented with a pageincluding a list of users as well as the option to enter username forsearch. At step S3208, the user chooses whether to enter search for useror to click on a user name. If a search is to be performed, at stepS3209, the user enters a user name and clicks on the Submit Button andflow proceeds to section A14. If the user wishes to click on a displayeduser, then at step S3210, the user clicks on a user's name and the flowproceeds to section A14. At step S3211, the user has the choice to resetthe user. At step S3212, the user clicks Reset User. At step S3214, theuser is presented with message to verify Reset/Don't Reset. At stepS3216, the user will verify to reset the user. At step S3217, if resetselected the user is presented with Success screen and the processterminates. If reset is not selected, at step S3218, the user ispresented with a request cancelled screen and the process terminates. Ifinstead, at step S3219, the user clicks Don't Reset, the flow alsoproceeds to step S3219.

FIGS. 22A and 22B are a flowchart of Transfer a PIC process. This is apermission based process, whereby only those users with properpermission may perform this process. At step S3300, the user ispresented with their homepage. At step S3302, the user clicks on theTransfer a PIC link. At step S3304, the user is presented with a pagewhere he can enter a PIC number to transfer. At step S3306, the userenters the PIC. At step S3308, the user clicks on the Submit Button. Atstep S3310, it is determined if the PIC exists in the system. If no, theflow proceeds to section B15. If yes, at step S3312, it is determined ifthe routing number belongs to acquiring bank. If no, flow proceeds tosection A15. If yes, and the PIC already belongs to an acquiring bank,flow proceeds to section B15. At step S3314, the user is presented witha PIC transfer screen. At step S3316, the user enters Current requestedPIC data. At step S3318, the user clicks on the Submit Button. At stepS3320, if it is determined if the current PIC info is complete andvalid. If no, flow returns to step S3314. If yes, at step S3322, theuser is presented with a PIC Customer Information screen and asked toconfirm and Request Transfer. At step S3324, it is determined if thecustomer information is Correct. If no, flow returns to step S3314. Ifyes, flow proceeds to section C15. At step S3326, the user is presentedwith a screen for them to enter new bank information. At step S3328, theuser enters PIC bank information and an effective date. At step S3330,the user clicks on the Submit Transfer Button.

At step S3332, it is determined if the PIC transfer info is complete andverified. If no, flow returns to step S3326. If yes, at step S3334, theuser is presented with a screen for them to verify new PIC information.At step S3336, it is verified whether the PIC transfer information iscorrect and the decision is made to transfer/don't transfer. If transferis selected, flow proceeds to section D15. If don't transfer isselected, the process terminates. At step S3338, a PIC transfer isentered into a database. At step S3339, the user is presented with asuccess screen and an explanation of the next steps. At step S3340, thereleasing bank is notified of a pending PIC transfer.

FIG. 23 is a flowchart of a Create a PIC process. At step S3400, theuser is presented with their homepage. At step S3402, the user clicks onCreate A PIC. At step S3404, a 7.0 NYCH/user validation Routine isperformed. At step S3406, the user is presented with the create a PICscreen. At step S3408, the user fills out all the required information.At step S3410, the user clicks on Submit and the flow proceeds tosection A16. At step S3412, the user is presented with the create PICscreen with data previously entered and may change data and the flowproceeds to step S3408. At step S3414, it is determined if the requiredfields are completed correctly. If no, flow proceeds to section B16 withan error message. If yes, at step S3416, it is determined if the DDAnumber does not have a PIC. If no, that is, if the DDA already has aPIC, the flow proceeds to B16 with an error message. If yes, at stepS3418, the user is presented with a screen that has the information theyentered and asked to verify—Create PIC, or the user can hit the backButton in the browser window. At step S3420, the user decides whether tohit create PIC or hit the back Button in the browser window. If at stepS3421, the user hits Create PIC, then at step S3422, the user ispresented with a Success screen that user has been deleted and theprocess terminates. If instead, at step S3423, the user hits back buttonin browser, the flow reverts to section B16.

FIGS. 24A and 24B are a flowchart of a Close a PIC process. PICs arenever deleted, merely closed. At step S3500, the user is presented withtheir homepage. At step S3502, the user clicks on Close PIC. At stepS3504, the user is presented with a page and asked to enter a PICNumber. At step S3506, the user types in a PIC number. At step S3508,the user clicks on submit. At step S3510, it is determined if the PICexists in the system. If no, flow returns to step S3504 with an errormessage. If yes, at step S3512, it is determined if the user has a rightto Close that PIC. If no, flow returns to step S3504 with an errormessage. If yes, flow proceeds to section A17. At step S3514, it isdetermined if the PIC has activity pending. If yes, at step S3516, theuser is presented with the current PIC data, which contains an ALERTwith an activity pending message. At step S3518, the user clicks to viewactivity pending data. At step S3520, the user is presented withActivity Screen. At step S3522, it is determined if the User is theowner of the Pending Activity. If no, the process terminates. If yes, atstep S3524, the user types in date and comments. At step S3526, the userclicks on Close PIC and flow proceeds to section B17. If the answerdetermined at step S3514 is no, then at step S3528, the user ispresented with the PIC screen with space for effective date andcomments. At step S3530, the user types in dates and comments. At stepS3532, the user clicks on Close PIC and the flow proceeds to sectionB17. At step S3534, it is determined if the date is a valid date. If no,the flow proceeds to section C17 with an error message. If yes, at stepS3536, the user is presented with a screen asking them are they surethey want to close PIC or Don't close PIC. At step S3538, the userdecides between Close PIC and Don't Close PIC. If, at step S3539, theuser hits Close PIC, then at step S3540 the user is presented with aSuccess screen that PIC has been closed and the process terminates. Ifinstead, at step S3541, the user hits Don't Close PIC, then at stepS3542, the user is presented with a Request Canceled Page and theprocess terminates.

FIGS. 25A and 25B are a flowchart of a Reactivate A PIC process. Toreactivate a PIC, it must belong to the bank. At step S3600, the user ispresented with their homepage. At step S3602, the user clicks onReactive PIC. At step S3604, the user is presented with a page and askedto enter a PIC. At step S3606, the user types in a PIC. At step S3608,the user clicks on submit. At step S3610 it is determined if that PICexists in the system. If no, flow reverts to step S3604 with an errormessage. If yes, at step S3612 it is determined if the user has rightsto reactivate that PIC. If no, flow reverts to step S3604 with an errormessage. If yes, flow proceeds to section A18, where, at step S3614 itis determined if the PIC has activity pending. If yes, then at stepS3616, the user is presented with the current PIC data which contains anALERT with an activity pending message. At step S3618, the user clicksto view activity pending data. At S3620, the user is presented withActivity. Screen. At step S3622, it is determined if the user is theowner of the Pending Activity. If no, the process terminates with anerror message. If yes, at step S3624, the user types in Date andcomments. At step S3626, the user clicks on Reactivate PIC and the flowproceeds to section B18. If the answer is no at step S3614, then at stepS3628, the user is presented with the PIC screen with space foreffective date and comments. At step S3630, the user types in Date andcomments. At step S3632, the user clicks on Reactivate PIC and the flowproceeds to section B18, where at step S3634, it is determined if theaccount is being recycled. If yes, the process terminates with an errormessage. If no, then at step S3636, it is determined if the date is avalid date. If no, flow proceeds to section C18 with an error message.If yes, then at step S3638, the user is presented with a screen askingthem are they sure they want to Reactivate PIC or Don't Reactivate PIC.At step S3640, the user decides whether to select Reactivate PIC orDon't Reactivate PIC. If, at step S3641, the user clicks Reactivate PIC,then at step S3642, the user is presented with a Success screen that PIChas been Reactivated and the process terminates. If instead, at stepS3643, the user clicks Don't Reactivate PIC then at step S3644, the useris presented with a Request Canceled Page, and the process terminates.

FIG. 26 is a flowchart of Contest/Release A PIC Pending Transfersprocess. At step S3700, the user is presented with their homepage. Atstep S3702, the user clicks on the Transfer Pending PIC Alert(s) orcontest transfer. At step S3704, the user is presented with a pageexplaining the Transfer(s) pending. At step S3706, the user decideswhether to Contest Transfer, Release, or Do Nothing. If, at step S3707,the user clicks on Contest, the flow proceeds to section A19. If, atstep S3708, the user does nothing, then at step S3709, transfer occursafter a predetermined number of days. If, at step S3710, the user clickson Release the flow proceeds to section B19. At step S3712, the user ispresented with a screen that explains the next steps. At step S3714, theuser checks a box to indicate a read message. At step S3716, system putsPIC in Contested status, and the process terminates. At step S3718, theuser is presented with a screen that asks if they are sure they want torelease. At step S3720, it is determined if there has been a release. Ifrelease, then at step S3721, the user clicks on Release, and at stepS3722, the user is presented with a success screen and the processterminates. If don't release is selected, at step S3723 the user clickson Don't Release and at step S3724, the user is presented with a requestcancelled screen, and the process terminates.

FIGS. 27A and 27B are a flowchart of an Approve A PIC Activity process.Examples of PIC activity that needs to be approved are Add, Delete, andModify. At step S3800, the user is presented with their homepage. Atstep S3802, the user clicks on the PICS Activity to Approve on home pageor PIC Approve. At step S3804, the user is presented with a page listingthe PICs they need to approve. At step S3806, the user clicks on a PIC.At step S3808, it is determined if the activity was entered by thisuser. If no, then at step S3810, the user is presented with a screenthat shows the information for that Activity for a PIC and the processproceeds to section A20. If yes, then at step S3812, the user ispresented with a screen that shows the information for that Activity fora PIC that explains they cannot approve it and the process terminates.At step S3814, the user can either Approve, Modify, Cancel. If at stepS3816, the user clicks on Approve, then at step S3818, the user is askedare they sure they want to approve. At step S3820, the user decidesbetween Approve and Don't Approve. If, at step S3821, the user hitsApprove, then at step S3822, activity is marked as approved in the Ic&sdatabase, and at step S3823, the user is presented with a success pageand the process is terminated. If, at step S3824, the user selects Don'tApprove, then at step S3825, the user is presented with a Success screenstating the item has not been approved and the process terminates. If,at step S3826, the user clicks on Modify, then at step S3827, the ModifyA PIC process is invoked (described later). If, at step S3828, the userclicks Cancel Activity, then at step S3830, the user is asked if theyare, sure they want to Cancel. At step S3832, the user decides betweenCancel and Don't Cancel. If, at step S3833, the user hits Cancel, thenat step S3834, activity is marked as canceled in the ic&s database, andat step S3835, the user is presented cancel request screen stating theactivity has been canceled, after which the process terminates. Ifinstead, at step S3836, Don't Cancel is selected, then at step S3837,the user is presented with a Success screen stating the item has notbeen canceled, after which the process terminates.

FIGS. 28A and 2813 are a flowchart of a Find A PIC process. All PICswill be retrieved based on a search criteria, including closed andpending PICs. Those PICs that a user cannot view or act upon, will alsoappear but be grayed out. At step S3900, the user is presented withtheir homepage. At step S3902, the user clicks on the Find A PIC Link.At step S3904, the user is presented with a page to search for a PIC. Atstep S3906, the user makes a choice as to what they wish to search by.If, at step S3908, the user enters a DDA/RT & Number to perform thesearch, then at step S3910, the user clicks on the Submit Button, and atstep S3912, it is determined if the required fields have been completedcorrectly. If no, flow proceeds to section A21. If yes, then at stepS3914, it is determined if the user requested Find by Co. Name & City.If no, then flow proceeds to section C21. If yes, flow proceeds tosection B21.

If, on the other hand, the search is to be by PIC number, then, at stepS3916, the user enters PIC Number and the flow proceeds to step S3910.If instead the search is to be by name and address, then at step S3918,the user enters the Company Name and City and the flow proceeds to stepS3910 and continues from there as discussed above. At step S3920, theuser is presented with search results preferably about 20 per page. Atstep S3922, the user clicks on the Company PIC info to view. At stepS3924, it is determined whether the User Bank is the owner of thecustomer. If yes, then at step S3926, the user is presented with theselected Company PIC information. If no, then at step S3928, the user ispresented with the selected Company PIC information in Abbreviated formIn either event, the process is then terminated.

FIG. 29 is a flowchart of View User Profile Activity Log process. Atstep S4000, the user is presented with their homepage. At step S4002,the user clicks on the User View Activity Link. At step S4004, it isdetermined if the user has access to multiple banks. If yes, then atstep S4006, the user is presented with page to search for Banks andmakes bank selection. At step S4008, the user is presented with page toenter search criteria for user activity and a list of the most recentuser activities for which he has access to. If no, the flow proceedsdirectly from step S4004 to step S4008. At step S4010, the user choosesto enter search data or to click on an activity. If the user chooses touse search criteria, then at step S4012, the user enters search criteriaand clicks on the Submit Button and the flow proceeds to section B22. Ifan activity is selected, the flow proceeds to section C22. At stepS4014, it is determined if the user request found selected criteria. Ifno, flow proceeds to section A22 with an error message. If yes, then atstep S4016, it is determined if the user has access to this information.If no, flow proceeds to section A22 with an error message. If yes, thenat step S4018, the user is presented with search results preferablyabout 20 per page. If at step S4020, the user clicks on the Useractivity to View, then step S4021, the user is presented with page ofUser activity information and the process terminates. Alternatively, atstep S4022, the user can click to search again, and the process returnsto section. A22.

FIGS. 30A and 30B are a flowchart of a Modify A PIC process. This is apermission based process, whereby only those users with properpermission may perform this process. View Only user will not be able toperform this process. Also, anytime a user gets a data entry error, thatuser is returned to the screen with the data they entered pre-filled. Atstep S4100, the user is presented with their homepage. At step S4102,the user clicks on Modify A PIC. At step S4104, the user is presentedwith a page and asked to enter a PIC Number. At step S4106, the usertypes in a PIC number. At step S4108, the user clicks on submit. At stepS4110, it is determined if that PIC exists in the system. If no, flowreturns to step S4104 with an error message. If yes, then at step S4112,it is determined if the User has rights to modify that PIC. If no, flowreturns to step S4104 with an error message. If yes, then flow proceedsto section A23. At step S4114, it is determined if the PIC has activitypending. If yes, then at step S4116, the user is presented with currentPIC data, which contains ALERT with activity pending message. At stepS4118, the user clicks to view activity pending data. At step S4120, theuser is presented with Activity Screen. At step S4122, it is determinedif the User is the owner of the Pending Activity. If no, an errormessage is produced and the process terminates. If yes, then at stepS4124, the user types in Modifications, Date and comments and the flowproceeds to section B23. Step S4124 may also be entered after executionof step S4126, at which a user is presented with an activity screen.

If the answer determined at step S4114 is no, then at step S4128, theuser is presented with an editable PIC Modify screen with space foreffective date and the flow proceeds to step S4124. At step S4130, theuser clicks on Modify PIC. At step S4132, it is determined if the Datawas entered correctly. If no, then at step S4134, the user is presentedwith a screen that has data they typed in so it can be corrected and theflow then returns to step S4132. Once the data is determined to beentered correctly, then at step S4136, the user is presented with ascreen that has data they typed in for verification and asked if theyare sure they want to modify PIC and the flow proceeds to section C23.At step S4138, the user clicks on Modify PIC, and at step S4139, theuser is presented with a Success screen and the process terminates.Alternatively, at step S4140, the user clicks on Cancel ModificationRequest, and at step S4141, the user is presented with a cancel requestscreen and the process terminates.

FIG. 31 is a flowchart of a Perform Trusted Third Party Validationprocess. At step S4200, it is determined if the User can perform one ormore functions on PICs for multiple banks. If no, flow returns to thecalling process. If yes, at step S4202, the user is presented with apage and asked to enter a bank name. At step S4204, the user types in abank name. At step S4206, the user clicks on submit and the flow returnsto. Create A PIC flowchart at step S3406.

FIG. 32 is a flowchart of a Validate Bank Profile process. This is aone-time process that occurs the first time a bank profile validatorlogs onto the system. Before any PIC activity can be accomplished, thebank profile must be validated. At step S4300, the user enters theUserid and password, and, at step S4302, hits submit. At step S4304, itis determined if the bank profile has been validated. At step S4306, itis determined if the User is A Validator. If yes, at step S4308, theuser is presented with the Bank profile page. If, at step S4310, theuser approves, then at step. S4312, the Bank Profile is Validated andthe user is presented with a Success screen. If at step S4313, the userchooses modify, then at step S4314, the process transfers to the to“Modify A Bank Profile” flow. If no at step S4306 or if yes at stepS4304, then at step S4315, the user is presented with their personalpage with appropriate menus.

FIGS. 33A and 33B a flowchart of an Approve A Bank Profile Modificationprocess. This process is for future use. Bank Profile activity thatwould have to be approved would be, for example, Add, and Modify. Theapproval loop is only necessary when specified on the bank profile. Atstep S4400, the user is presented with their homepage. At step S4402,the user clicks on the Bank Activity to Approve. At step S4404, the useris presented with a screen that shows the information for that BankActivity. At step S4406, it is determined if a Activity to be approvedwas created by user. If yes, then at step S4408, the user is presentedwith a screen that shows that bank activity. At step S4410, the user caneither Modify, or Cancel the Request. If, at step S4412, the user clickson. Modify, then at step S4413, process Modify A Bank Profile 1.4 iscalled. If, on the other hand, at step S4414, the user clicks CancelActivity, then the flow proceeds to section A. If the answer at stepS4406 is no, then at step S4416, the user can either: Approve, Modify,or Cancel the Request. If at step S4418, the user clicks on Approve,then the flow proceeds to section A. If, at step S4420, the user clickson Modify, then at step S4421, the Modify A Bank Profile 1.4. process iscalled. If instead, at step S4422, the user clicks Cancel Request, theflow proceeds to section A. At step S4424, the user is presented with ascreen that asks if they are sure they want to do that activity. At stepS4426, the user must decide to do activity or cancel request foractivity. If, at step S4428, the user clicks to do activity, then atstep S4429, the user is presented with a Success screen and the processterminates. If instead, at step S4430, the user clicks on cancel requestfor activity, then at step S4431, the user is presented with a Successscreen stating the request was canceled, and the process terminates.

The PIC system provides for Batch File updates. FIG. 34 illustrates thePIC Batch service. Files are received over either a secure privatenetwork (SWIFTNet) 34.4 or using an existing private CONNECT: Direct34.1 network to a Bulk File Disk Storage 34.2. The files are then routedto a Bulk File Server 34.3. The PICBatchService recognizes this file andprocesses it. The executable program:

-   -   Starts a Windows Service in FileMonitorService.vb using the        System.ServiceProcess. ServiceBase Class. This includes methods        to control starting, pausing, continuing and stopping the        service.    -   Within the method OnStart of the Service class, StartMonitor is        called. This instantiates an object from the MonitorFiles class        in MonitorFiles.vb: This object will then use the        System.IO.FileSystemWatcher Class to monitor the file system for        new files.    -   FileSystemWatcher.WaitforChange is then called to wait for new        files being created in the input directory. When a file is        created the FileSystemWatcher notifies the service by calling        MonitorFiles.OnFileCreated, which queues a request to a thread        pool. Multithreading is managed by using the        System.Threading.Thread Class in.NET    -   The Thread will process the incoming file calling ProcessFile in        class Importer. After obtaining exclusive use, the File will be        moved to a working directory and then validated for a        recognizable File Name format. Valid File Names will continue to        be processed. Unrecognized File names will be reported to the        Event Log and the thread process will then end.    -   File formats are then validated for the Incoming Batch File.    -   If format is correct then update requests are sent to the PIC        database by calling the Business Facade Project, The request        will pass through the Business Rules and Data Access Projects,        performing validations and updates into the PIC database.    -   All results are received from the Business Facade as a Dataset.    -   An Output file will be generated in a temporary working        directory based on the results. When the file is complete it        will be moved to the appropriate Output Directory.    -   All phases of the batch process will use exception and        notification trace logs to track both incoming and outgoing        batch files. It will use the System Diagnostic namespace which        exposes methods that allow logging of trace messages. This also        includes interfaces to MOM 2000 and Event logs.

The file formats consist of a Header record, followed by multiple DetailRecords, which is followed by a File Control Record. Tables 6 and 7depict the PIC Input Load File Format and the PIC Output Load FileFormat, respectively.

TABLE 6 PIC INPUT LOAD FILE FORMAT: FIELD NAME TYPE SZ COLUMNS REQUIREDCOMMENTS INPUT FILE HEADER HEADER INDICATOR N 1 1 * Indicates FileHeader. Always must be “1” SENDING BANK R/T N 9  2-10 * R/T of Banksending File RECEIVING BANK R/T N 9 11-20 * IC&S Routing Transit NumberFILE CREATION DATE N 8 21-28 * Date File was created. Format YYYYMMDDFILE MODIFIER N 2 29-30 * File Sequence Identifier FILER AN 770  31-800DETAIL INDICATOR N 1 1 * Indicates File Header. Always must be “6” PICDETAIL ACTION AN 6 2-7 * Files Originated from Bank: CREATE = add a newPIC MODIFY = change an existing PIC TRANSFR = transfer a PIC fromanother bank CLOSE = deactivate a PIC REACT = reactivate a PIC PICIDENTIFIER AN 17  8-24 Input will be zero filled for CREATE UPDATEEFFECTIVE N 8 25-32 Date update is effective Zeros assumes next DATEbusiness date Format is YYYYMMDD PIC STATUS N 2 33-34 * Must be “00” onInput File EPN CAPABLE N 1 35  * Valid Values: 0 = No 1 = Yes CHIPSCAPABLE N 1 36  * Valid Values: 0 = No 1 = Yes BANK RT NUMBER N 937-45 * FED's rt for this bank, or Rt # for customers bank DDA ACCOUNTNUMBER AN 34 46-79 * DDA account number EPN has maximum of 17 char (LeftJustified) TAXPAYER ID AN 12 80-91 * NAME ANS 96  92-187 * Corporate orindividual's name ADDRESS 1 ANS 64 188-251 * First Address line ADDRESS2 ANS 64 252-315 * Second line of address Required if Address 3 ispresent ADDRESS 3 ANS 64 316-379 * Third line of address Required ifAddress 4 is present ADDRESS 4 ANS 64 380-443 * Fourth line of addressCITY ANS 32 444-475 STATE/PROV ANS 32 476-507 POSTAL CODE AN 11 508-518COUNTRY ANS 3 519-521 * Values defined by ISO-3166 3-letter codes. SICBUSINESS CODE N 4 522-525 Standard Industrial Classification codes DUNESID AN 10 526-535 D&B D-U-N-S Numbers BIC CODE N 11 536-546 SWIFT BICCode BEI CODE N 11 547-557 SWIFT Business Entity Identifier IBAN CODE N34 558-591 International Bank Account Number WIRE PAY N/A 1 ANS 35592-626 CHIPS/Fed Wire Payment Name/Address 1 WIRE PAY N/A 2 ANS 35627-661 CHIPS/Fed Wire Payment Name/Address 2 WIRE PAY N/A 3 ANS 35662-696 CHIPS/Fed Wire Payment Name/Address 3 WIRE PAY N/A 4 ANS 35697-731 CHIPS/Fed Wire Payment Name/Address 4 FILLER AN 69 732-800Filled with spaces ADDITIONAL NOTES: Required Fields lists above for theInput Detail Records apply only for “Create”, “Modify” and “Transfer”Actions. The fields required for “Close”, and “Reactivate” are asfollows: CLOSE: DETAIL INDICATOR N 1 1 * Indicates File Header. Alwaysmust be “6” PIC DETAIL ACTION AN 6 2-7 * CLOSE = deactivate a PIC PICIDENTIFIER AN 17 25-32 * Date update is effective Zeros assumes nextbusiness date Format is YYYYMMDD FILLER AN 768  33-800 REACTIVATE:DETAIL INDICATOR N 1 1 * Indicates File Header. Always must be “6” PICDETAIL ACTION AN 6 2-7 * REACT—Reactivate a PIC PIC IDENTIFIER AN 17 8-24 * Input will be zero filled for CREATE UPDATE EFFECTIVE DATE N 825-32 * Date update is effective Zeros assumes next business date Formatis YYYYMMDD FILLER AN 768 33-80 INPUT FILE CONTROL CONTROL INDICATOR N 11 * Indicates File Control. Always must be “9” This is Last record onFile. TOTAL DETAIL RECORDS AN 793  8-800

TABLE 7 PIC OUTPUT LOAD FILE FORMAT: FIELD NAME TYPE SZ COLUMNS COMMENTSOUTPUT FILE HEADER HEADER INDICATOR N 1  1 Indicates File Header. Alwaysmust be “1” SENDING BANK R/T N 9  2-10 IC&S Routing Transit NumberRECEIVING BANK R/T N 9 11-20 R/T of Bank sending File FILE CREATION DATEN 8 21-28 Date File was created. Format YYYYMMDD FILE MODIFIER N 2 29-30File Sequence Identifier REJECTED FILE IND N 1 31 Values: 0—File wasAccepted 1—File was Rejected REJECTED TEXT AN 50 32-71 This will listthe Error message if an input file is rejected FILER AN 729  72-800OUTPUT FILE DETAIL DETAIL INDICATOR N 1  1 Indicates File Header. Alwaysmust be “6” PIC DETAIL ACTION AN 6 2-7 Valid values are ACCEPT—PICdetail action request accepted by IC&S ERROR—PIC detail action requestdenied, Associated text begins in column 751 PIC INDETIFIER AN 17  8-24Zero filled for CREATE that was denied UPDATE EFFECTIVE DATE N 8 25-32Date update is effective Format YYYYMMDD PIC STATUS N 2 33-34 ValidValues: “00”—Create request was deined “01”—Open (Active) “02”—Closed(Inactive) “03”—Transfer in Process “04”—Transfer being contested“05”—Awaiting approval via Web “06”—Request scheduled for Effective dateto be Implemented “99”—Suspended EPN CAPABLE N 1 35 Valid Values: 0 = No1 = Yes CHIPS CAPABLE N 1 36 Valid Values: 0 = No 1 = Yes BANK RT NUMBERN 9 37-45 FED's rt for this bank, or Rt # for customers bank DDA ACCOUNTNUMBER AN 34 46-79 DDA account number EPN has maximum of 17 char (LeftJustified) TAXPAYER ID AN 12 80-91 NAME ANS 96  92-187 Corporate orindividual's name ADDRESS 1 ANS 64 188-251 First Address line ADDRESS 2ANS 64 252-315 Second line of address Required if Address 3 is presentADDRESS 3 ANS 64 316-379 Third line of address Required if Address 4 ispresent ADDRESS 4 ANS 64 380-443 Fourth line of address CITY ANS 32444-475 STATE/PROV ANS 32 476-507 POSTAL CODE AN 11 508-518 COUNTRY ANS3 519-521 Values defined by ISO-3166 3-letter codes. SIC BUSINESS CODE N4 522-525 Standard Industrial Classification codes DUNS ID AN 10 526-535D&B D-U-N-S Numbers BIC CODE N 11 536-546 SWIFT BIC Code BEI CODE N 11547-557 SWIFT Business Entity Identifier IBAN CODE N 34 558-591International Bank Account Number WIRE PAY N/A 1 ANS 35 592-628CHIPS/Fed Wire Payment Name/Address 1 WIRE PAY N/A 2 ANS 35 627-661CHIPS/Fed Wire Payment Name/Address 2 WIRE PAY N/A 3 ANS 35 662-696CHIPS/Fed Wire Payment Name/Address 3 WIRE PAY N/A 4 ANS 35 697-731CHIPS/Fed Wire Payment Name/Address 4 FILLER AN 19 732-750 Filled withspaces ERROR TEXT AN 50 751-800 Text for error if detail record wasrejected OUTPUT FILE CONTROL CONTROL INDICATOR N 1  1 Indicates FileControl. Always must be “9” This is Last record on File. TOTAL DETAILRECORDS N 6 2-7 Total Number of Detail Records on File. ACCEPTED RECORDSN 6  8-13 Total number of PIC updates Accepted REJECTED RECORDS N 614-19 Total number of PIC updates Rejected TOTAL RECORDS N 6 20-25 TotalNumber of Records on File. Count of All records including Header,Details, and Control. FILLER AN 775  26-800

A Configuration File named PICBatchService.EXE.Config is also beincluded. This is an XML file that must be included in the same path asthe executable program. Included in <App Settings> are elements for:

-   -   Connection String    -   Input File Path    -   Incoming Working Path    -   Temporary Output File Path    -   Output File Path for Connect Direct    -   Output File Path for SWIFT

File Titles for processing:

Input Batch Files:

Path—\“Input Path”\RT\Source\File Name

-   -   Input Path—From Configuration File    -   Source—Connect Direct=CD        -   SWIFT=SWIFT    -   File Name—UINYYYYMMDD99.DAT        -   Where: YYYYMMDD—File Creation Date        -   99—File Sequence (Start 1 thru 99)

Output Batch Files:

-   -   Path—\“Output Path”\RT\Source\File Name        -   Output Path—From Configuration File        -   Source—Connect Direct=CD            -   SWIFT=SWIFT        -   File Name—UOUTYYYYMMDD99.DAT            -   Where: YYYYMMDD—File Creation Date                -   99—File Sequence (Start 1 thru 99)

Each file for an RT should have a unique Creation Date and Modifier.

There will be fields designated as required and optional Requests to“Close” and “Reactivate” will have a limited number of required fields.

Detail records requesting a “Transfer” will only be accepted if theentire file contains Transfer requests.

Output files will always return the entire PIC record.

These will be Binary files in ASCII format without CR & LF characters.

The IC&S RT will be used as the Receiving RT for incoming batch filesand the Sending RT for Outgoing batch files.

A file that is not formatted properly will be rejected.

Possible file format errors include:

1. Missing File Header Record

2. Invalid Sending RT for File

3. Invalid Receiving RT for File

4. File Control is not last record

5. Total detail records on File Control is incorrect

Rejected files will be returned as an Output File with

1. Reject File Indicator of “I” and Error Text in Output File Header.

2. Accepted Records of 0 in Output File Control

3. Rejected Records count will be equal to Total Detail Records in FileControl.

Detail errors will be designated by “ERROR” in the PIC Detail Actionfield of the Output batch file and added to the Rejected totals count.

Specific error text will be included as part of the Output File Formatwhere noted.

While the present invention has been described with respect to what ispresently considered to be the preferred embodiment, it is to beunderstood that the invention is not limited to the disclosedembodiment. To the contrary, the invention is intended to cover variousmodifications and equivalent arrangements included within the spirit andscope of the appended claims. The scope of the following claims is to beaccorded the broadest interpretation so as to encompass all suchmodifications and equivalent structures and functions.

1-15. (canceled)
 16. A payment method, comprising: determining whether afirst routing identifier included in a payment instruction has routinginformation for a financial institution, the payment instruction alsoincluding a payee-related identifier; if the first routing identifier isdetermined to include routing information for a financial institution,then transmitting a payment message based on the first routingidentifier, the payment message including the payee-related identifier;and if the first routing identifier is determined to not include routinginformation for a financial institution, then: retrieving payee-relatedaccount identification information and a second routing identifier basedon the payee-related identifier, and transmitting a payment messageincluding the payee-related account identification information to apayee-related destination, based on the second routing identifier, thepayment message not including at least one of the payee-relatedidentifier and the first routing identifier; wherein the steps above areperformed by at least one computer processor.
 17. A method according toclaim 16, wherein at least one of the determining and transmittings isperformed by a payment system.
 18. A method according to claim 17,wherein the payment system is an automated clearing house (ACH).
 19. Amethod according to claim 17, wherein the payment system is afunds-transfer system.
 20. A method according to claim 16, furthercomprising: managing data stored at a database, the data including atleast one of a name and the second routing identifier; and generating anaccess request to the database for at least the second routingidentifier.
 21. A method according to claim 20, wherein the database isa secure database of a trusted third party.
 22. A method according toclaim 16, further comprising providing an instruction to debit anaccount of a payor.
 23. A method according to claim 16, wherein thepayee-related destination is a first financial institution, and whereina payee account is credited at at least one second financialinstitution.
 24. A method according to claim 23, further comprisingcommunicating between the first financial institution and the at leastone second financial institution to effect crediting of the payeeaccount.
 25. A method according to claim 23, wherein each paymentmessage also specifies a value representing an amount to be paid, andwherein a payee account is credited based on the value.
 26. A methodaccording to claim 16, wherein the retrieving is performed at a thirdparty entity.
 27. A method according to claim 16, wherein at least oneof the determining and transmittings is performed electronically.
 28. Amethod according to claim 16, further comprising validating thepayee-related identifier against a database of codes.
 29. A methodaccording to claim 16, wherein the account identification informationincludes at least an account number of a payee account.
 30. A methodaccording to claim 16, wherein the first routing identifier does notidentify a financial institution.
 31. A method according to claim 16,wherein the second routing identifier does not identify a payeefinancial institution.
 32. A method according to claim 16, wherein thepayment instruction is initiated from a payor.
 33. A method according toclaim 16, wherein the payment instruction is initiated from a financialinstitution.
 34. A method according to claim 16, further comprising apayor providing the payee-related identifier to initiate the paymentinstruction.
 35. A method according to claim 16, further comprising: ifthe first routing identifier is determined to not include routinginformation for a financial institution, then replacing thepayee-related identifier included in the payment instruction with theretrieved payee-related account identification information and replacingthe first routing identifier with the second routing identifier.
 36. Amethod according to claim 16, wherein the first routing identifier is aunique pseudo-code, and the payee-related identifier is a further uniquepseudo-code.
 37. A system comprising: a determining unit that determineswhether a first routing identifier included in a payment instruction hasrouting information for a financial institution, the payment instructionalso including a payee-related identifier; and a transmitting unitconfigured to if the first routing identifier is determined to includerouting information for a financial institution, transmit a paymentmessage based on the first routing identifier, the payment messageincluding the payee-related identifier, and if the first routingidentifier is determined to not include routing information for afinancial institution, then: retrieve payee-related accountidentification information and a second routing identifier based on thepayee-related identifier, and transmit a payment message including thepayee-related account identification information to a payee-relateddestination, based on the second routing identifier, the payment messagenot including at least one of the payee-related identifier and the firstrouting identifier, wherein the units above are included in at least onecomputer.
 38. A non-transitory computer readable medium having storedthereon sequences of instructions, the sequences of instructionsincluding instructions which, when executed by a computer system, causethe computer system to perform a method comprising: determining whethera first routing identifier included in a payment instruction has routinginformation for a financial institution, the payment instruction alsoincluding a payee-related identifier; if the first routing identifier isdetermined to include routing information for a financial institution,then transmitting a payment message based on the first routingidentifier, the payment message including the payee-related identifier;and if the first routing identifier is determined to not include routinginformation for a financial institution, then: retrieving payee-relatedaccount identification information and a second routing identifier basedon the payee-related identifier, and transmitting a payment messageincluding the payee-related account identification information to apayee-related destination, based on the second routing identifier, thepayment message not including at least one of the payee-relatedidentifier and the first routing identifier.
 39. An apparatuscomprising: at least one memory storing a computer program; and at leastone computer processor coupled to the at least one memory, and operatingunder control of the computer program stored in the at least one memory,to: determine whether a first routing identifier included in a paymentinstruction has routing information for a financial institution, thepayment instruction also including a payee-related identifier, if thefirst routing identifier is determined to include routing informationfor a financial institution, then transmit a payment message based onthe first routing identifier, the payment message including thepayee-related identifier, and if the first routing identifier isdetermined to not include routing information for a financialinstitution, then: retrieve payee-related account identificationinformation and a second routing identifier based on the payee-relatedidentifier, and transmit a payment message including the payee-relatedaccount identification information to a payee-related destination, basedon the second routing identifier, the payment message not including atleast one of the payee-related identifier and the first routingidentifier.
 40. An apparatus according to claim 39, wherein the at leastone processor is associated with an automated clearing house (ACH). 41.An apparatus according to claim 39, wherein the at least one processoris associated with a funds-transfer system.
 42. An apparatus accordingto claim 39, wherein the at least one computer processor also operatesunder control of the computer program to: manage data stored at adatabase, the data including at least one of a name and the secondrouting identifier; and generate an access request to the database forat least the second routing identifier.
 43. An apparatus according toclaim 42, wherein the database is a secure database of a trusted thirdparty.
 44. An apparatus according to claim 39, wherein the at least onecomputer processor also operates under control of the computer programto provide an instruction to debit a payor account.
 45. An apparatusaccording to claim 39, wherein the payee-related destination is a firstfinancial institution, and wherein a payee account is credited at atleast one second financial institution.
 46. An apparatus according toclaim 45, wherein the first financial institution and the secondfinancial institution communicate to effect crediting of the payeeaccount.
 47. An apparatus according to claim 45, wherein each paymentmessage also specifies a value representing an amount to be paid, andwherein a payee account is credited based on the value.
 48. An apparatusaccording to claim 39, wherein retrieval of the payee-related accountidentification information includes accessing such information via athird party entity.
 49. An apparatus according to claim 39, wherein theat least one computer processor also operates under control of thecomputer program to validate the payee-related identifier against adatabase of codes.
 50. An apparatus according to claim 39, wherein thepayee-related account identification information includes at least apayee-related account number.
 51. An apparatus according to claim 39,wherein the first routing identifier does not identify a financialinstitution.
 52. An apparatus according to claim 39, wherein the secondrouting identifier does not identify a payee-related financialinstitution.
 53. An apparatus according to claim 39, wherein the atleast one computer processor also operates under control of the computerprogram to: replace the payee-related identifier included in the paymentinstruction with the payee-related account identification informationand replace the first routing identifier with the second routingidentifier, if the first routing identifier is determined to not includerouting information.
 54. An apparatus according to claim 39, wherein thefirst routing identifier is a pseudo-routing number, and thepayee-related identifier is a pseudo-account number.